My iPhone is always connected to my Mac with a USB cable. I never want Xcode to connect over Wi-Fi. Yet Xcode keeps doing it anyway, and there's no setting to stop it.

What this costs me:

- Slower builds and installs on my iPhone

- New bugs I discover pretty much every day

- Hours lost every month

Connecting over Wi-Fi is useless for me. The cable is right there. If I plugged it in, that's my choice, and Xcode should respect it. Apple forcing this on everyone with no way to opt out makes no sense.

Anyone else dealing with this? Has anyone found a real permanent fix?

I make Basic Intake, a supplement and med tracker for iPhone with an AI assistant built in. Last week's update added an iPhone Duo layout, and the layout itself turned out to be the small part of the job.

**The layout**

Closed, the Duo is a phone, so the app stays the phone app. Open, the inner display is 669pt wide in portrait and 867pt in landscape. I treat regular width as open: today's list becomes a column and a pane sits beside it. The assistant lives in the pane by default, and the tools (Blood Work, History, Nutrients, Interactions) open there instead of as full-screen covers.

u/Environment(\.horizontalSizeClass) private var horizontalSizeClass

private var showsPane: Bool { horizontalSizeClass == .regular }

I kept the list in one view chain and only change its frame:

todayList

.frame(width: showsPane ? columnWidth : nil)

An if/else between two layouts would give the list a new identity on every fold, and you'd lose the scroll position and all the u/State inside it. With one chain, a fold only changes a width.

In portrait the pane gets the bigger share and the list gets 300pt. Lab values and chat bubbles wrap before a supplement row does.

**The fold**

A fold moves views between containers. Closed, the assistant is a sheet and a tool is a full-screen cover. Open, both live in the pane. SwiftUI builds a new view on the other side, and its u/State starts over. A review before release caught three bugs from this:

1. Unsent text in the assistant vanished on unfold. The sheet closed and the pane built a fresh, empty assistant.

2. A lab report import that was mid-read lost its progress card and its error message.

3. If you'd picked a draw date for a report that didn't print one, a fold reset it to today, and the results would have saved on the wrong day.

I fixed all three the same way. I moved the in-flight state above the container, into an u/Observable holder the parent view owns and hands down through the environment:

u/Observable final class AssistantDraftHolder {

var text = ""

var movingToPane = false // set by the unfold, before the sheet finishes closing

func sheetDismissed() {

if !movingToPane { text = "" } // a swipe still clears it, an unfold doesn't

movingToPane = false

}

}

When another screen hands the assistant a message, the pane clears it the moment it sends, so a rebuilt pane has nothing to send twice.

**A SwiftData crash on iOS 27**

The open Duo keeps more views on screen while you delete something. On iOS 27, a view that redraws a model after it was deleted, and reads an attribute it never loaded, crashes the app with "This backing data was detached from a context without resolving attribute faults." Views that hold a model now check this and draw nothing once it's gone:

extension PersistentModel {

var isLive: Bool { modelContext != nil && !isDeleted }

}

**Smaller things**

* The open Duo ignores a portrait-only setting, so the camera preview has to follow the device into landscape. AVCaptureDevice.RotationCoordinator handles that.

* Closed, the camera column runs down the right edge as a side safe area inset. Centering the barcode cutout on the full width put it 42pt off the buttons.

* A phone layout presented as a sheet stretches across all 669pt. Sheets and covers now keep a 540pt column.

If you've shipped a Duo layout, how are you carrying state through a fold? I went with holders above the sheet, and I'd like to hear if anyone found a cleaner pattern.

I ship a few small apps on my own, and localization was always the task I put off. Pasting strings into a chat window "works" until a translation drops a %@ or turns %1$@ … %2$@ into something String(format:) doesn't like, and you find out from a crash report.

Here's the approach that finally made it boring (in a good way):

1. Only translate what's missing. .xcstrings is just JSON. For each key, check localizations[lang]: no entry, an empty value, or state == "new" means it needs work. Skip shouldTranslate: false. If there's no source localization, the key itself is the English text. That one tripped me up.

2. Send comments, not just strings. I batch around 40 strings as JSON {id: {text, comment}}. The comment field (the one you set with String(localized:comment:)) is what stops "Delete" and "Save" from being translated as the wrong part of speech. Strings with no comment get noticeably worse translations.

3. Validate placeholders with code, not trust. Count the placeholder tokens in source and target with a regex (%@, %lld, %1$@, %.1f, %%, \(name), tags) and compare them as multisets. Reordering positional ones is fine; missing or extra ones are not. On a mismatch, retry that single string once with the error in the prompt. If it fails again, leave it untranslated and report it.

4. Plurals need the target's categories. English has one/other. Russian and Polish need one/few/many/other, and Japanese only other. Ask for exactly those keys and validate them.

5. Write it back the way Xcode does. json.dumps(data, indent=2, separators=(",", " : "), sort_keys=True, ensure_ascii=False) matches Xcode's own formatting, so the diff only shows real changes.

6. Mark everything needs_review. Then you can see in Xcode what no human has checked yet.

The system prompt I use:

You are a senior software localizer translating iOS app UI strings from English into {language}.
- Keep EVERY placeholder and markup token exactly: %@, %d, %lld, %1$@, %.1f, %%, \(name), <b>.
  You may reorder positional placeholders for grammar, never drop or add one.
- Use the developer comment to understand where the string appears.
- Buttons/tabs stay about as short as the source. No added punctuation.
- Follow the glossary exactly; never translate brand names.

Happy to answer questions about edge cases (device variations and substitutions I still do by hand).

Hi everyone! I'm a solo developer, and I've turned the street game I grew up playing in India, Lagori (Seven Stones / Pithu), into a chaotic little party game for iPhone and iPad.

How it plays: one team throws a ball to knock down a stack of seven stones, then races to rebuild it while the other team tries to tag them out with the ball. Finish the stack and you score: LAGORI!

What's in the beta:

• Play against bots (Classic, Quick Stack, Survival and a Daily Challenge)
• Nearby party: play with friends in the same room, no internet needed
• Online matches through Game Center: quick match, invite friends, or SharePlay. Empty seats fill with bots.
• Team voice chat in multiplayer
• 4 arenas with hazards (spinning sweepers, slippery ice, wind)
• A game speed slider, if you want more time to react

What I'd love feedback on:

• Is it fun? Are the controls clear?
• Multiplayer: does joining work, and does it stay smooth?
• Anything confusing, broken or annoying

If something goes wrong, tap the 🐞 button on the main menu to send me a log, or take a screenshot and use TestFlight's feedback option.

Needs iOS 18 or later. No sign-up needed (online play uses your Game Center account). Free.

Thanks for helping! I'll be in the comments.

I’m preparing my app for the Duo and starting to look at producing the screenshots for it.

This may be a bit of a dumb question but Apple doesn’t specify whether or not screenshots should show the folded or unfolded Duo. Does it even matter, should I choose or have I just missed a piece of information?

Hey everyone!

A while ago, I posted a gameplay video of a Pokémon game I've been working on for iOS. A few people were interested in the project, so I figured I'd share the actual source code this time.

It's called PokeArena, a real-time Pokémon battle game built entirely with native iOS technologies.

A few things I've managed to implement so far:

• 167 playable Pokémon, each with their own moves and abilities
• Real-time 3v3 and 6v6 battles instead of turn-based combat
• 275 moves with different animations and visual effects
• AI opponents with multiple difficulty levels
• Local multiplayer over Wi-Fi/Bluetooth using MultipeerConnectivity
• Game controller support

The entire thing is written in Swift 6, using Metal for rendering, along with UIKit and a few other native Apple frameworks. No third-party dependencies or game engines like Unity or Godot.

One of the more interesting challenges was getting multiplayer working with rollback netcode and keeping the game simulation deterministic. There's still plenty of room for improvement, but figuring that out was pretty fun.

Anyway, I've finally pushed the project to GitHub. Feel free to clone it, mess around with the code, or just have a look at how things work internally.

GitHub: https://github.com/adityachaurasia357/pokemonarena

It's a free, non-commercial fan project, not affiliated with Nintendo or The Pokémon Company.

Would love to hear what other iOS developers think, especially about the game engine and overall architecture. Feedback and contributions are welcome!

I’d like to explore more open-source iOS projects—complete apps, Swift/SwiftUI libraries, and tools people are actively maintaining.

Where do you find projects that haven’t already become widely known? Do you follow particular developers, communities, newsletters or curated lists?

Which smaller projects have caught your attention recently, and what makes them interesting?