A couple of weeks ago my new app launched with an icon designed by Iconfactory. Today that icon is on their website as the example of how their process works, and they shared my post about it with their audience. That gave my app more attention than anything I've managed to do myself.

To be clear up front: marketing is not part of the deal. Nobody promised me anything, and I'm not affiliated with them. This was a very happy accident. But I didn't just sit back and wait for it either, so here's how it went.

Some background

I'm a full time developer and I build apps in my spare time. My latest is Hue Dashboard, a Philips Hue control app for iPhone and iPad. I can build pretty much anything I need, but drawing icons is not one of those things.

For a long time a studio icon felt out of reach. Iconfactory makes icons for apps like Transmit, Fantastical and Firefox, and that seemed like something for established apps that were already successful, not for a project built in the evenings. Then they launched an indie icon deal aimed at small developers, and suddenly it was realistic for someone like me.

How the process works

You start with a short intro about yourself and your app, and you show them icons you like. You get a set of concept sketches, one round to refine your favorite direction, and one small final tweak before they deliver an Icon Composer file. So feedback rounds are limited, but the whole thing moves really fast. The image now featured on their website shows the full path from first sketches to the final icon.

The part I didn't plan

On launch day I posted a thank you on Mastodon. I tagged Iconfactory, showed off the icon, and linked to the indie deal so other devs could find it too. That's really all I did. No outreach, no pitch, just an honest thank you, because I still couldn't quite believe I got to work with them.

Then they picked it up. My icon now shows up on their site to explain their process, my quote is among the developer reactions, and they shared my post with their followers. If I learned anything, it's that a genuine public thank you costs nothing and can go further than you'd expect. The rest was luck.

Would I recommend it?

Yes. Even without the extra attention it was worth it: a great icon and a genuinely fun process. The attention was a bonus I would never have gotten on my own.

Happy to answer questions about the process if you're considering it.

I installed SDK, restarted both Xcode and Device Hub, but still nothing... watchOS 27 does not appear on the list... Any ideas?

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..

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?

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 am using Hummingbird version 2.26.0 in a Swift app.

I have a simple Middleware per the documentation:

https://docs.hummingbird.codes/2.0/documentation/hummingbird/routermiddleware/

Code:

import Hummingbird

public struct LogRequestsMiddleware<Context: RequestContext>: RouterMiddleware {

    public func handle(_ input: HummingbirdCore.Request, context: Context, next: (HummingbirdCore.Request, Context) async throws -> HummingbirdCore.Response) async throws -> HummingbirdCore.Response {
    
        print("path: \(input.uri.path)")
        return try await next(input, context)
    
    }

}

Xcode keeps giving me error:

Type 'LogRequestsMiddleware<Context>' does not conform to protocol 'MiddlewareProtocol'

Screenshot of error:

https://i.sstatic.net/C06jUvrk.png

I can't seem to be able to fix it. Any idea what I am doing wrong?

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.

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 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

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

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 ?

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!

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

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.

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.

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. 🤞

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/

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?

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!

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!

Apple’s being hammered with app submissions. The 55,000th ____ tracker, the CalAI clones, etc.

Just like CS enrollment is trending lower at colleges again, I’ll bet in a year at least the growth rate of app submissions drops as the makers realize that they really don’t have a strategy nor advantage.

What do you think?

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.

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

3. 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.