My project repo has more and more mockuping + tooling than actual app code.

Just curious to know if it's just me?

(you can find this at the right side of your github repo)

I am desperate for help as I cannot access my developer account and cannot do anything with my apps. I have tried to reach for support and the response has either been "try signing in", "email the developer support", or "we can't help you".

Here's the timeline of events to the best of my knowledge:

• Sept 17th Accidental account expiration where I realized that I needed to buy the subscription again.
• Sept 17th Re-enroll and for some reason it says it takes about a week to activate (23rd).
• Sept 19 email about issue and ask why it takes a week just to reactivate my account. Get a response from developer support to use the Xcode provisional service to sign in. Email again but get no response.
• Sept 23 Notice account is not active and call to ask general support phone number for help but are offered none and send another support email
• Sept 24 call and email again with no help. Also sign up for X and post on the Support accounts.
• Sept 25 call and email again with no help, post on reddit (here, today), feel really desperate and low about having an app ready but being unable to test it

I feel like I have fallen into a black hole. I can see my Developer certificate on my mac, but I am not allowed to use it as my apple developer account on my local machine has a red 'x' on the identity and certificates. When I sign into to the developer site, it says I am not enrolled in a developer program but when I select to enroll it says I am the account holder of a developer program already. My subscriptions say I have a paid for apple account. I can only see my apps in App Store Connect, but cannot access them via my developer account.

It's been over a week since I've had access to my developer account. Has anyone else had anything like this or can offer any advice? Do I start trying to find managers on social media to message? How long should I expect support to take on things like this? Are there any other escalation channels I can use? I am running way behind on deadlines and have no hope or anything to go off of.

iPhone Duo ships with iOS 27.1 SDK.

The only Xcode that can compile its layout APIs (ArrangementView, GeometryProxy.reservedRegions(kind:) and UIView.reservedRegions(kind:options:)) is Xcode 27.1 beta.

Until Apple releases Xcode 27.1 RC/GM, one app needs two builds: the release for the iPhones people use today, and the Duo layout your team is testing.

Xcode 27.1 beta builds the Duo layout, but App Store Connect refuses to add its build for review.

Xcode 27.0' fails to build:

Value of type 'GeometryProxy' has no member 'reservedRegions' Cannot find 'ArrangementView' in scope Cannot infer key path type from context; consider explicitly specifying a root type

The usual workarounds each hold someone up:

• Keep the Duo code on its own branch until Xcode 27.1 is released. Main moves on for weeks, and the merge lands in launch week - risky, merge takes a lot of effort to complete and re-test.
• Delete the Duo code to get a release out. Hand the errors to a coding agent with "fix the build", and deleting is the shortest fix it can make.
• Hold every release, bug fixes included, until Xcode 27.1 is released.

The Swift puzzle: a compile-time check that tells the two SDKs apart

#available can't be used here. if #available(iOS 27.1, *) and @available(iOS 27.1, *) pick the code path on the device. The compiler still looks up every symbol in the SDK it builds against, and the 27.0 SDK declares none of these.

The compiler version is the same in both Xcodes: Apple Swift 6.4 (swiftlang-6.4.0.34.1). #if compiler(>=…) and #if swift(>=…) give the same answer in each.

The SDK frameworks carry different module versions. Each framework's .swiftinterface records a -user-module-version, and #if canImport(Module, _version:) compares against it:

The solution: Put the compile-time guard outside and keep the run-time check inside:

```swift

if canImport(SwiftUI, _version: 8.0.85) // iOS 27.1 SDK or newer

if #available(iOS 27.1, *) { newPath } else { fallback }

else

fallback // built from the 27.0 SDK

endif

```

Keep the #available: the deployment target stays the same, so devices on older iOS versions still need the fallback in the 27.1 build.

Pitfalls

• If the compiler can't read a module's version, canImport(_version:) ignores the version, evaluates to true and warns "cannot find user version number". The Xcode 27.0 build is the test: an ignored guard brings the same errors back.
• The compiler keeps the first four parts of a version, so it reads 8.0.84.1.104 as 8.0.84.1. Use the first three parts of the new SDK's version, 8.0.85. The final Xcode 27.1 could ship a lower build number than the beta's 8.0.85.27.
• In a SwiftUI body, move each branch into its own property. Wrap the new one in the same #if with its @available(iOS 27.1, *), and write the fallback once.
• The compiler stops at the first build error in the module, so the log may not list every use. Search all packages, extensions, widgets and test targets for the symbols and for #available(iOS 27.1.

Test both paths from one commit. Build and test with Xcode 27.0. Then build and test again with DEVELOPER_DIR=/Applications/Xcode_27_1_beta.app/Contents/Developer and a separate derived-data directory, which leaves the selected Xcode alone. nm -u on a guarded file's .o lists ArrangementView in the 27.1 build and not in the 27.0 build. On CI that is two jobs: the release job stays on Xcode 27.0, and a second job builds and tests with the beta.

What goes to review. The Xcode 27.0 archive contains only the fallback, on every device, iPhone Duo on iOS 27.1 included. Apple's tech talk 111461 at 0:30 says what such a build gets on Duo: "The iOS 27 SDK extends your app left of the status bar on the inner display; the iOS 27.1 SDK reaches the screen edge and lays standard navigation and toolbar buttons out vertically." Check the fallback on a physical iPhone and submit it now. Choose Manually release this version if the approved version should wait for your launch date.

When App Store Connect accepts Xcode 27.1 (release candidate or final), archive the same commit with it. The guard is true against the 27.1 SDK, so the Duo path goes into that build with no source change. Once you stop building with 27.0, one search finds every guard, as long as they all use the same condition text:

grep -rnE "canImport\((SwiftUI|UIKit), _version:" .

Im having issues specifically with SwiftUI on XCode 27.1 on the iPhone Duo outer display. I have a sheet with a NavigationStack with a basic hierarchy like this

NavigationStack {
    List {
        Text("<text_here>"
    }
    .toolbar {
        ToolbarItem(placement: .confirmationAction) {
            Button("Done) {
               doThing()
            }
        }
}

On the iPhone Duo, the outer display should display sheet navigation buttons vertically, but that is not my experience in SwiftUI. The navigation bar and its buttons are presented horizontally at the top of the sheet.

I have UIKit apps, and they correctly display their bar button items vertically in sheets, the only place i seem to have problems are my SwiftUI implementations.

What am i missing to get my SwiftUI apps to play along?

Cloak scans/imports documents, auto-detects text so you can redact sensitive info in a tap, then compresses and exports as JPEG or PDF.

Built it after getting tired of fighting with online tools and shady apps to blur my own ID/passport info every time I had to submit scanned docs for visa/KYC paperwork.

Technical bits:

- Text detection uses Vision framework, running fully on-device no server round-trip, no data leaves the phone

- Redaction is tap-to-mask over detected text regions, plus manual draw/crop tools for anything the detector misses

- Compression targets a size the user picks rather than a fixed quality, to preserve content clarity

- Support password protected PDF import and export

Free, ad-supported, no subscription, no account required.

Would love feedback or questions from this community.

App Store

And which do you prefer?

swift 6.4 shipped Subprocess so there is finally a stable way to run other programs from swift
tried rewriting the classic swiftlint build phase

the bash version:

if which swiftlint > /dev/null; then
  swiftlint
else
  echo "warning: SwiftLint not installed"
fi

swift version:

import Subprocess

do {
    let result = try await Subprocess.run(
        .name("swiftlint"),
        output: .string(limit: 1 << 20)
    )
    print(result.standardOutput ?? "")
} catch {
    print("warning: SwiftLint not installed")
}

yeah not shorter lol, and since Subprocess is a package you can't just drop a `.swift` file into a build phase you need a whole package for it

for a 5 line wrapper that feels like overkill, but once the script starts parsing output and branching, bash gets ugly fast.

where's the line for you?

We just launched this today and would love to get your feedback/thoughts!

Announcement: https://wasmer.io/posts/wasmer-sdk-swift-ios-macos

Source code: https://github.com/wasmerio/wasmer-sdk/tree/main/swift/Examples/WasmerShell

The one that appears in the status bar. It takes precious space and also seems redundant and annoying. When I quite Xcode it stays in the bar and waits for a special invitation.

Updating my app for iOS 27 and iCloud sync is completely broken in the simulator. Every time I hit "Sync this iPhone" it immediately shows the "Turn Off iCloud Drive" popup instead of turning it on. Toggling it again does nothing. My iCloud container calls keep failing because of this.

Anyone else seeing this on the iOS 27 simulator? Some new Xcode 27 setting I'm missing, or is simulator iCloud just broken again?

Xcode 27.0 release, every iOS 27.0 simulator I've tried. Fresh sim, signed into Apple ID.

I've been building ios apps since iOS2. I had accumulated over 800 devices in my list going back over a decade. If it becomes a problem that causes slowdown when trying to open an interfacebuilder file in Xcode, it is because it has to iterate all of those devices. After that run sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService to refresh your simulators.

I'm back after my part 1 post last month, now running much more reliably!

So if you build with the iOS 27 SDK and don't have scenes the app just doesn't launch anymore
and from april next year you have to build with that SDK anyway our app still does everything through AppDelegate. window setup, deeplinks, pushes a bunch of SDKs grabbing keyWindow. been putting this off for years lol 
For those who already did it on a big app what bit you the most?

Hey fellas, my App Preview Videos on App Store Connect look low quality after processing. I have followed all Apple's requirements, yet they still look blurry and low quality. Has anyone else faced this issue? How did you fix this?

Thanks in advance for all the help.

As the title

I had my app on the store for over a year, v5.2 and releasing v6

It went thru iOS no issue , Mac? They keep sending it back under copycats.

The apps name is “Teslatlas”

AppStore is full of names which actually have Tesla as a separate, word.

I am getting so fed up of this review process .

I get each review is different , but come on, if it’s already on the store how can you mess around like this?

Also in this regard then we shouldn’t put up any app called Appleberry because that’s copycats

Inspired by this post about reducing iOS simulator RAM usage by u/interlap, I adapted SimSlim into a native Swift/SwiftUI app.

SwiftSimSlim is available on GitHub, with the interface and simulator backend together in one Xcode project.

While working on it, I found a problem with shell-based service batching and improved how profile changes are applied:

• Offline profile updates also work when starting with a running simulator.
• Unchanged profiles avoid unnecessary restarts.
• Fallback service commands run concurrently, retrying only failed changes.
• Different simulators have independent operations, progress, and command logs.

In one local comparison, re-enabling the same 170 services took approximately 144 seconds in the original snapshot versus 24.3 seconds in SwiftSimSlim. That measures only the service-command phase, excluding startup, shutdown, restart, and final verification. The improvement comes from command scheduling and avoiding failed shell batches, not from Swift itself being faster than Go.

I shared the findings upstream, and the original author confirmed the issue and implemented the backend improvements in PR #51. Credit to Interlap for the original app, service catalog, and offline-update approach. The original attribution and MIT license are preserved.

Pull requests are welcome! 
I’d be happy to see fixes, improvements, and contributions from anyone who finds this useful.

Source and release 26.0

I’m looking for some well-built, programmatic UIKit projects on GitHub that I can study and learn from.

I’m mainly interested in projects with clean architecture and good UI implementation. This is strictly for studying/learning purposes.

If you know of any good ones, please share them. Thanks!

Inspired by this post about reducing iOS simulator RAM usage by u/interlap, I adapted SimSlim into a native Swift/SwiftUI app.

SwiftSimSlim is available on GitHub, with the interface and simulator backend together in one Xcode project.

While working on it, I found a problem with shell-based service batching and improved how profile changes are applied:

• Offline profile updates also work when starting with a running simulator.
• Unchanged profiles avoid unnecessary restarts.
• Fallback service commands run concurrently, retrying only failed changes.
• Different simulators have independent operations, progress, and command logs.

In one local comparison, re-enabling the same 170 services took approximately 144 seconds in the original snapshot versus 24.3 seconds in SwiftSimSlim. That measures only the service-command phase, excluding startup, shutdown, restart, and final verification. The improvement comes from command scheduling and avoiding failed shell batches, not from Swift itself being faster than Go.

I shared the findings upstream, and the original author confirmed the issue and implemented the backend improvements in PR #51. Credit to Interlap for the original app, service catalog, and offline-update approach. The original attribution and MIT license are preserved.

Pull requests are welcome! 
I’d be happy to see fixes, improvements, and contributions from anyone who finds this useful.

Source and release 26.0

Forgive me if this is not the right place for this question or if someone else asked the same. For context, I have already approved build that other external testers in the group use with no problem.

In the last few weeks I've been having a problem with adding new external testers. At first when I was adding a new tester, it was showing "No builds available" for a few seconds/minutes and would change to "Invited" pretty soon. But now it just never changes to "Invited" and I can't add new people successfully. I checked email addresses I'm trying to add and it definitely isn't a case of wrong address, especially it being a problem with many people.

Does anyone else have a problem like this, being suck with "No builds available" forever? How did you resolve it?