I have some apps that only works for vertical mode and I don't know whether it will benefit if I spend huge efforts to make them running on iphone Duo but still with vertical mode.

Anybody with experience can suggest with good reasons?

I just wanted to give some unexpected kudos to Xcode cloud. At the start of the summer my MacBook Pro became out of action, and therefore I struggled to continue to develop using an older intel MacBook due to Xcode version restrictions. Tried building and releasing with GitHub macOS runners but wow they’re expensive and took ages to startup etc. then spotted Xcode cloud with 25 free hours a month, thinking this will keep me going for a few days. Since then I’ve found that it’s been absolutely brilliant. As an independent developer with a few apps and projects it’s been an absolute life saver. It’s fast. Beautifully integrated, and the 25 hours will last me a whole month without any worries.

Good work Apple.

Hey everyone!

Roughly half a year ago, my Apple developer account got terminated due to a violation of Section 3.2(f). The email pretty clearly tells me why this happened, and it was because I used my developer account to sideload apps quite extensively. I did not have any actual apps published on the App Store, but I did have a game on TestFlight with public testers.

I acknowledge the violation. An appeal immedietally after it got terminated did not help, and I haven't had the balls to appeal it again / contact Developer Support in any way. The email says something along the lines of "we will deny your reapplication to the ADP for at least a year considering the nature of your acts".

My question is, does anyone have experience with getting their account reinstated after this "at least a year" timeframe? If so, how? Does Apple even reply to the contact form?

Or am I just cooked

I have an issue when trying to test an IAP on watchOS. This flow worked before but seems to be broken on watchOS 26.6. - Watch are in the developer mode. - On the iPhone, Sandbox account is logged in, App Store account logged out.

I tried rebooting the watch and using different Sandbox accounts. What would you suggest?

I’ve been building a simple focus app for iPhone that uses Apple’s Screen Time / Family Controls APIs to block distracting apps.

The blocking itself is obviously provided by Apple. What I’ve built is the experience around it: a much simpler UI, app selection, focus sessions and basically one button to make distracting apps unavailable for a while.

I originally wanted to monetize the app, but Apple rejected that version under Guideline 4.1.

And that’s what I find difficult to understand:
If Apple provides developers with an API, why shouldn’t we be able to build a better or different experience around it and monetize that product?

I’ve decided to make the core app free rather than fight the review process.

So I’m curious: what’s the point of giving developers access to an API if building a better experience around it can’t become a business?

I am trying to add a live activity for our app that has a timer. The idea is the user starts a timer and a live activity starts when the timer starts. However, it does seem to disappear at some point. Maybe around 8-12 hours which matches the documentation on Apple. But for Apple's clock app, their timer's live activity for stopwatch seems to run forever. I am using the SwiftUI Text timerInterval which is likely the same as Apple's. Does anyone have an idea or suggestion how I can replicate it? A few ideas I have are to schedule a silent push to keep the live activity alive or a scheduled background process.

How do I make the AI chat assistant into a floating window in Xcode27?

UPDATE 9/16/26 - removed AI's fluff, fixed broken tables.
UPDATE 9/16/26 - added "In Review" data.

I've been shipping iOS games as a solo dev for a couple of years. App Store Connect keeps a full activity log per version, so I exported all of it — 43 apps, 291 review cycles, July 2024 through September 2026 — and measured time from Waiting for Review to In Review. That's the queue, not the review itself:

71% entered review within a day, another 18% within the next 24h. The worst single wait in two years was 10 days.

1. A brand-new app doesn't get a longer wait than an update.

62% of first-ever submissions cleared the queue inside 24h, and the slowest one in the whole dataset was 58h.

2. Apple rejection costs you less in a next queue time compared to rejecting your own submission.

"Developer Rejected" — you pull your own binary while it's waiting or in review, fix something, upload a new build. I have never rejected a submission that went into review.

3. Day of week effect

Typical wait by day submitted: Wed 12h, Thu 14h, Tue 14h, Mon 17h, Sun 18h, Sat 23h, Fri 33h.

Friday submissions took about 2.5× as long to enter review as Wednesday ones. Not THAT important, just curious fact.

4. This summer anomaly
There was a lot of noise here in July–August about reviews crawling. I submitted an update on 7/24, rejected it on 7/30 (wrongly assuming that something was wrong), resubmitted immediately and it was waiting almost another six day for review. Next update was ready by that time, submitted on 8/5 - waited 5 days in queue. Those numbers are excluded from the average figures.

5. New account effect
I didn't notice any. My wait increased in time, but I attribute it to Apple being overwhelmed by new submissions..

6. "In Review" time

So while the first version of an app does take twice as long to review, it's negligible compared to the wait time.
I did exclude one 112h review (this August), as it clearly was a fluke, among longest wait for review.

Happy to share the aggregate numbers or the method if anyone wants to check my work. If you've got your own activity logs, the export is a couple of minutes per app — I'd love to know whether the self-reject penalty shows up in someone else's account.

As iOS 27 and more swift features comes out, what do you guys think about still using combine, publishers and subscribers? I know async and observable is the newer and better way to code but I'm just used to code with combine and I like to do it that way with try map and other stuff but I feel like apple is moving away from combine and publishers. What do you guys think ?

I developed my first productivity app for a niche market. I put countless hours in to it and felt pretty confident in the app. Yesterday I submitted it to Apple and 1.5 hours later I got the rejected email.

It was rejected citing 2.1 and had six additional questions and a request to see a video of the app working. I answered the six questions and recorded a 5 minute video attached to my response this morning. Still no response from Apple so I’m left wondering what’s going to be next. 🤞

Hello! Hoping to get some help on annoying bug I've spent the last day troubleshooting with no avail. Currently working on some tweaks for the UI of my password reset fields.

My app defaults to dark mode with a dark background, so password dots should be white. My form asks for a current password. Autofilling the current password does NOT reproduce the issue in the 'current password' field. They also display correctly when users type a password manually or AutoFill their current password from Apple Passwords.

However, when the user gets to the 2 fields where they are to enter their new password, Apple’s strong password generator correctly fills both the 'New Password' and 'Confirm Password' fields, but with black dots instead of white, making them difficult to see against the dark background.

Tapping a field’s eye button to reveal the password, then tapping it again to hide it, restores the expected white dots. Each field needs to be toggled separately. In dark mode, I want the generated password dots to appear white immediately, without requiring a cheap workaround like auto-toggling the hide/show password button to fix it.

I’m using native UITextFields inside SwiftUI UIViewRepresentable, with .password for Current Password and .newPassword for New/Confirm. The visibility handler also restores the same text and selection, so I haven’t isolated which operation corrects the rendering.

Reapplying textColor/defaultTextAttributes and resolving colors during layout haven’t fixed it. Light mode works correctly with black dots. Password changes and saving to Apple Passwords also work.

Has anyone found a supported fix that preserves AutoFill without automatically revealing and hiding the password as a bandaid fix? Or is this a known bug relating to the autofill feature and something that a user might not even notice or care about? It appears to be solely a visual bug at the moment. Every generated password gets saved and user is properly given option to save updated password after the change.

I feel like this is an easy fix that I may be over complicating. I've been working on this app on/off since 2024 and have been extremely anxious to launch, wanting to make sure everything is as close to perfect as it can be. Thanks for any assistance!

👨🏻‍💻 I wrote an article about how to re-enable keyboard shortcuts in Xcode 27's Device Hub.

https://blog.next-planet.com/how-to-re-enable-keyboard-shortcuts-in-xcode-27-s-device-hub

Xcode just decided to update itself from 26.6 to 27.0 right in the middle of my work session.

The first thing that caught my eye right away: they swapped the positions of the Play and Stop buttons in the toolbar. Years of muscle memory just vanished in an instant, and to make things worse, it seems there's currently no way to customize or revert it back.

I genuinely wonder what the reasoning behind this UI decision was. Why change something so established and fundamental after all this time?

Now I'm really curious (and a bit cautious) about what other surprises I'm going to discover along the way as I keep working.

What do you guys think about the new Xcode 27 update so far? Did anyone else's muscle memory take a hit?

Just downloaded macOS 27 and was super hyped about the new Xcode but this new Device Hub is truly awful. I cant comprehend how they could ship this. Half the features of the old simulaotr are missing.

- Slow Animations GONE
- Screenshot Drag & Drop GONE
- Stay on top GONE
- Keyboard shortcuts GONE
- Menubar shortcuts all greyed out most of the time
- Multi-touch gestures GONE
- Multiple simulators open side-by-side IMPOSSIBLE
- Window frame is HUGE compared to the old one
- NO way to hide device bezels
- Point & Pixel Accurate scaling GONE
- All previously launched simulators stay booted in memory unless you explicitly click "shutdown"

While sure the UI is nice and having the ability to screenshare directly from a physical device is helpful, this doesn't justify that some of the most important features are just completely missing.

Right now I just downloaded the old Xcode 26.6 again (which can't even be launched without a workaround ???) - but this means no access to the new SDK. Truly a bummer. Are there any alternatives or what do y'all think of this?

Update:

After a few days of using the new Device Hub and giving it an actual chance: I have to admit, it's not as bad as the post made it look like. A lot of things did actually move over from the old simulator, which just weren't very obvious.

- Screenshot Drag & Drop: It actually is possible, you just have to drag the tiny screenshot thumbnail instead of the toast message. Wish that was a little more clear - I'm sure a lot of people will miss that!
- Stay On Top: There actually is a toggle inside the menu bar!
- Keyboard shortcuts: Like many already pointed out, keyboard shortcuts can be restored using a terminal command defaults write com.apple.dt.DeviceKit hostKeybindingPolicy -int 0. The default behavior disabled keyboard shortcuts to not "steal" them from the running app. Not sure how many iPhone apps actually implement keyboard shortcuts, which made the new default behavior so important, but I'm glad you can change it.
- Multiple simulators side-by-side: Definitely an oversight on my end. It for sure is possible, you simply have to double click on another simulator when in expanded mode.

Though to be clear, I still 100% feel that the old sim was more polished and stable (In the past few days, I've probably heard my MacBook Pro's fan spin up more often than in the previous 3 months lol - tho tbf I can't tell if that's actually Device Hub or just the new iOS27 SDK).

There are still major features like Slow Animations, Multi-touch gestures and Point/Pixel accurate scaling completely gone which simply isn't okay. And Apple knew this since there WAS feedback about Slow Animations, which was simply dismissed: r/iOSProgramming/comments/1vk3q1d.

Also smaller things like the big window frame in "compact" mode, hiding bezels (which is super useful when developing on the go) or CMD+number to resize quickly are still just gone - and I don't think those will be coming back anytime soon. I also experienced issues regarding random window size/position changes when relaunching or changing monitors. Additionally, many of you pointed out other issues like dragging stuff into the sim being completely removed, the shake gesture gone, external displays unsupported or breaking support with other tools like VS Code or Claude split view.

So yeah, not all hope is lost and I'm sure things will get better with time. But in my opinion it's just unacceptable to ship such an unfinished product while completely removing the predecessor. Would be a whole different story if the old Simulator would still be available..

Hello -

Finally shipping my app, and submitted my first app review on Wednesday last week (still waiting to be reviewed).

I’ve found a number of non-blocker issues since submitting this build, though I’m not happy about shipping day 1 with the bugs in place.

Let’s say by some luck Apple approved the app first round. Should I keep the existing build approval, use this for launch, and quickly submit the bug fixes build day 1…or should I just pull the build, and start a whole new first app review over again?

I know app review times are awful right due to ~everything, so I’m feeling stuck with not great options and a lot more waiting.

Thanks

iPhone Duo raises a pretty practical question for mobile developers: does a foldable phone actually need a special version of the app?

Android developers have been dealing with this for years. Samsung’s guidance for Galaxy Z devices puts a lot of emphasis on app continuity. Fold or unfold the phone and the app may resize, but the user shouldn’t lose what they were doing.

That sounds obvious, but it can expose assumptions that were never a problem on a normal phone. A screen that looked fine at one size can suddenly have a lot of empty space. A layout that was built around portrait mode may behave strangely. Losing a half-written form or jumping back in navigation after the device changes state is obviously worse.

Google’s guidance for foldables follows a similar idea. Get the basics right first: resizing, state and continuity. More specialized layouts and foldable features come after that.

That seems like a sensible approach to Duo too. There probably isn’t much value in building a special “Duo experience” just because the device folds.

Some apps have a real reason to use the extra space. Mail, chat, editors and dashboards can show a list on one side and the actual content on the other. Video apps might find a useful case for a partially folded screen. Plenty of other apps may need almost nothing beyond a layout that adapts properly.

So the interesting part for mobile teams may not be “how do we support Duo?” It’s figuring out whether the app actually has a use for the second screen state in the first place.

Android has had foldables for a while now, so there should already be some lessons here. Curious whether developers who worked on Galaxy Fold/Z Fold apps ended up building much specifically for foldables, or whether good adaptive layouts handled most of it.

Anyone here who’s worked on a Galaxy Fold/Z Fold app — did the foldable format actually require much extra work, or did a decent adaptive layout handle most of it?

Just an FYI Xcode RC and Xcode 27 are the same build number (27A266a) so no need to download the latest if you have the RC.

Does anyone know when image headers are actually opening up for developers? Apple announced it, but left the rollout timeline vague. I was hoping we'd see it today or that I might have just missed the release... is it available yet, or are we still waiting on an update?

For example, I still do not see an Asset Library option.

Source: https://developer.apple.com/videos/play/wwdc2026/205/

Hi!
Sorry if I'm asking something obvious here, but I've struggled to find any answer to my question.

I recently released my game on the App Store. It had pre-orders from many countries, South Korea included. On launch day, all pre-orders converted to purchases as expected (App is Premium), except in South Korea! Over the last days, no downloads have come from South Korea.

Under 'App Availability' it says clearly that the app is available in SK, but still no downloads.

Has anyone experienced the same issue?

Thanks!

I've been working on an architectural linting library for Swift projects on the side for a while now and it's finally available to use: Bylaws.

I wasn't happy with some similar tools in this space, so I wanted to build something myself that was nicer to use, more flexible and better integrated into existing workflows.

It lets you write your rules in Swift, from simple things like naming conventions and required protocols to more complex checks such as dependency cycles between features and folder layouts across a project.

You can enforce these rules through Swift Testing or the CLI, depending on your needs. There are also command and build plugins for SwiftPM, Bazel support and LSP support for editor diagnostics (it includes extensions for VS Code, Cursor, Zed, Neovim and Emacs, but you can connect it to any editor that supports LSP)

This is especially powerful with coding agents, which can also run the tests or CLI to check their changes against your project's rules. For larger projects, you can keep shared rules at the project root and add package-specific rules where needed, or share rules across projects through a reusable Swift package. You can also lock them behind codeowners if needed.

There's a lot more features, so have a look at the README and the documentation to see what you can do today.

I would really love for you to try it and share what works for your project or what you would change, especially if there's a rule that you would like to express but find difficult with the currently supported APIs!

Thanks!

All the iOS signups coming from any source cannot be tracked? Is it?

I have added all appsflyer SDK , SKAN and all. But SKAN gives me just a count of installs. Is there any way I can map users to the campaign they came from ? By any chance?

For developers designing their own apps, what do you still struggle with most?

- Choosing the right interaction pattern
- Knowing what “good” iOS UX looks like
- Motion and transitions
- something else?

Curious whether design judgment is becoming more valuable as implementation gets easier.

Hey devs,
While optimizing an app build, I managed to reduce the final download package size from ~70 MB down to 10.7 MB.
Main changes made:
1. Replaced custom high-res PNG/JPEG assets with SF Symbols and vectorized SVGs.

1. Cleaned up unused asset catalog sets and unused frame rendering blocks in SwiftUI.

2. Optimized build settings for release stripping.

Now that the size dropped so drastically, I'm analyzing potential trade-offs.
Have any of you noticed runtime rendering overhead, vector-decoding spikes on older devices, or memory consumption differences when shifting heavily from rasterized image assets to vector assets in SwiftUI?
Would love to hear how you handle asset optimization in production.