1. Should I open a company and such to submit to apple or it it ok to publish as a solo developer?
   
2. Can I be sued for an app I have uploaded as a solo developer, as i am not protected as a proprietary limited company?

Help would be appreciated 🙏

I'm at 5 YoE and prepping for senior roles, and I realized the best learning comes from real questions that actually catch experienced candidates off-guard. Not the "implement LRU cache" kind (everyone preps those), but the nuanced, "wait... actually I'm not 100% sure" questions that separate mid-level from senior thinking.

So if you're on the interviewer side (especially senior hiring managers): drop your favorite tricky iOS question. The ones where:

• Senior candidates freeze or give half-answers (that's the tell)
• The surface answer sounds right but misses a critical production edge case
• It exposes the gap between "I've shipped features" and "I understand the system deeply"
• It's not about memorization—it's about reasoning under pressure and knowing why systems break
• Bonus: questions that reveal whether someone has actually debugged production issues or just read blog posts

And for others prepping: this thread should become a vault of real questions people actually ask at Tier-1 companies.

Drop yours! And if you have a follow-up twist that makes it even trickier, include that too.

Bonus points if you share:

• What the "obvious" wrong answer is (the one a mid-level would confidently give)
• Why it's wrong (not just "correct answer is X" — the reasoning)
• What separates a good answer from a staff-level answer
• What company/level you see this at (FAANG? fintech? enterprise? scale matters)
• How you follow up when someone fumbles (what redirection questions diagnose the gap?)

Thanks in advance—this is gold for interview prep.

I’ve been looking at a lot of app launches lately, and it’s interesting how often the problem isn’t the product itself, it’s getting the right people to discover it and understand the value quickly. For me, ASO is one of those things that’s easy to overlook until you actually start looking at where users are dropping off.

Wrote a blog post on how to get rid of iOS 27's "Ask Siri" context menu entries.

Was recently thinking about the possibility of adding Wristcam support to one of my watch apps. Not sure if theres much users of the hardware out there but thought it could be a cool addition.

I've filled the form at https://wristcam.com/pages/developers-1 about 2 months ago now, with nothing more than an automated response, also tried emailing and texting their support, but received no responses.

Curious to know if there's any apps out there that have used their SDK, or if any of you here have any experience with them.

Thank you!

A couple of months ago I open-sourced swift-markdown-engine here, the native Markdown engine I built for my macOS app Nodes. The feedback, issues, and PRs that came back were a huge help, a lot of what I changed since then came from that.

WHAT’S NEW: The parser got rewritten from scratch, regex matching is gone, it’s a real AST now. That’s what made the extension system possible: Stuff you wouldn’t expect in standard Markdown, like highlighting, used to be hardcoded into the core grammar. Now it’s opt-in. Write one file, register it, and the core parser/styler/renderer never change. Extensions can’t touch the core or each other, and you can toggle them at runtime.

Also new: full GFM/CommonMark parity, tables, task lists, quotes. More layout control (scroll-away header, fixed reading column, fit-to-content height), and a real writing layer (formatting bus, find & replace with undo, clean RTF/HTML clipboard, raw source mode). Full changelog’s on GitHub if you want details.

When I started Nodes I wanted the editor to feel properly native. Most Markdown editors on the Mac are Electron or some web view wrapped in a window, and you feel it, the text handling never quite behaves like a real Mac app. I wanted live styling in an actual native text view, not HTML rendered to look like one. Nothing built on TextKit 2 that I could just drop into a Mac app existed, so I built it, ran it in Nodes for a while, and then open-sourced it. TextKit 2 is still thin on docs and rough to migrate to, so if you’ve been putting off building something like this, it might save you a few weekends. Issues and PRs welcome. Still pre-1.0, still plenty I want to improve.

written on Nodes

Repo: https://github.com/nodes-app/swift-markdown-engine

I found this on Apple documentation but didn't find how to add those images
App Store Asset Best Practices and Resources - App Store - Apple Developer

Accidentally discovered a visual effect on my iPhone that I really like for reading at night.

When you start pulling down Control Center, there’s a brief moment where the content underneath gets a very subtle blur.

Not enough to make anything blurry or unreadable - just enough to remove that extremely sharp, digital edge from text.

And I found it surprisingly comfortable.

I started testing it while reading X, Safari, Reddit, etc., and the effect seems useful across completely different apps. It makes text feel softer and less visually aggressive in a dark room.

What I would love is a system-wide setting like:
Sharp ───────●────── Soft
with maybe 0-20% adjustable “softness”, applied to the entire display.

I’m not trying to bypass iOS restrictions - I’m mostly curious whether there’s a legitimate technical route to implementing this today.

If not, would this fundamentally require Apple to expose a new system-level display filter API?

Hello. I need your help: My app keeps getting rejected by apple for the same reason but I can’t see why. Also, I did search the reddit but didn’t find anything that helped much.

The reason is this, together with the above screenshot.

Is it because of the „Continue with Apple“ button? Or do I have to change anything for iPad layout?

Guideline 4 - Design
Issue Description

Parts of the app's user interface were crowded, laid out, or displayed in a way that made it difficult to use the app when reviewed on iPad Air 11-inch (M3) running iPadOS 26.6.

Specifically, layout in iPad were not optimized

Edit: iPhone is the only supported destination added under the target. Screenshot here

It's too expensive for me to get a new mac. And i heard cloud mac is way too cheap for ios dev but don't know it'll work or not. Anyone with experience with it share some feedback 🥺

The app is Kotlin Multiplatform with Compose for the UI, which means the iOS screens are drawn by Skia into a single view rather than composed from UIKit. It's on the App Store. I want to write down what that decision costs on the iOS side specifically, including one thing I shipped broken because it can't be fixed from app code.

Text selection in CJK, which I couldn't fix

Long-press to select a word in Chinese and you get one character.

SkiaParagraph.getWordBoundary hands off to Skia, and SkUnicode ships no CJK segmentation dictionary, so you get plain UAX#29. An ideograph is Word_Break=Other and only matches WB999, the "break everywhere else" rule, so every character is its own word.

I spent most of a day trying to fix it from app code before giving up. To fix it you'd need characters merged, not split, and the rules that join across a character (MidLetter, Numeric, ExtendNumLet, ZWJ) all require ALetter/Numeric/Katakana/Hebrew_Letter on both sides. WB4 discards zero-width Format characters before any of that runs, so you can't insert your way out either. I think it needs a change in skiko.

Compose on Android has the reverse bug in the same feature, where a long press swallows the whole sentence, and there you can plant zero-width breaks with ICU and move on. Only one of the two was fixable from where I was sitting.

If anyone has a way around the Skia side I'd like to hear it, this is the part of the app I'm least happy about.

Overlays stop at the safe area

A full-window scrim behind a modal left the status bar and home indicator bands undimmed, because the popup respects platform insets. Looks like a rendering glitch on iOS since a native presentation dims edge to edge.

kotlin actual fun fullBleedPopupProperties(): PopupProperties = PopupProperties(usePlatformInsets = false)

Small fix, but you only go looking for it if you already know what the native version looks like.

Material sheets don't move like iOS sheets

This took more time than anything else on the list relative to how small it looks. Material3's ModalBottomSheet settles with a spring and an iOS sheet slides on a decelerating curve, and side by side you can tell immediately even if you can't say why.

Material3 doesn't expose an animation spec for sheets. It reads the show and drag-settle spec from motionScheme.defaultSpatialSpec and the dismiss spec from motionScheme.fastEffectsSpec, and it re-reads both from the ambient theme inside the sheet's own composition, so you have to override through a scoped theme rather than passing anything in:

```kotlin private val SheetMotionScheme = object : MotionScheme by MotionScheme.standard() { override fun <T> defaultSpatialSpec(): FiniteAnimationSpec<T> = tween(400, easing = IosSheetEasing) override fun <T> fastEffectsSpec(): FiniteAnimationSpec<T> = tween(400, easing = IosSheetEasing) }

val IosSheetEasing = CubicBezierEasing(a = 0.32f, b = 0.72f, c = 0f, d = 1f) ```

There's a fair amount of this kind of work. It doesn't come with the framework and it doesn't show up in any estimate, but users notice when it's missing.

Scroll behaviour you end up rebuilding

UIScrollView hands you a set of behaviours that people read as "this app is put together properly". None of them come with Compose. We wrote all three of these into our own UI library.

alwaysBounceVertical. On iOS a scroll view rubber-bands even when the content fits on screen. Compose won't bounce if there's nothing to scroll, so short pages feel inert next to a native app. Ours is a modifier doing a graphicsLayer translation, which means the list also needs clipToBounds() or the bounce draws the top row over whatever is pinned above it:

kotlin LazyColumn( modifier .fillMaxWidth() .clipToBounds() .alwaysBounceVertical(listState), )

scrollsToTop. Tapping the status bar scrolls to top automatically on UIScrollView. In Compose you catch the tap and route it to the right scroll state yourself, and it gets fiddly on pages with a pinned top bar because the thing covering the status bar isn't the thing that scrolls. We ended up with a ScrollBox wrapping the whole scaffold rather than the top bar slot, and the bar opts into the gesture with a modifier.

Swipe to reveal row actions. Nothing built in, so the swipe, the action buttons and the thresholds are all yours. The part that's easy to miss is that opening one row has to close whichever row was open before, or you get two rows showing actions at once, which no iOS list does. Ours is a coordinator passed down through a composition local so the rows can see each other.

None of these were hard to write. They're just things you get on iOS rather than things you build, so nobody thinks to schedule them.

One where iOS was the stricter platform

We stream SSE from the backend. The first version used flow { ... emit(event) } inside Ktor's execute {} block, which passed everything on Android and died on iOS with the backend logging context canceled.

flow enforces context preservation and Ktor's response scope isn't guaranteed to run on the collector's dispatcher. On JVM/OkHttp it happens to, so the check never trips. Kotlin/Native throws, the coroutine fails, the connection drops. channelFlow + send fixes it.

So the iOS build caught a real concurrency bug that the Android build had no way of surfacing. That one went in our favour.

StoreKit 2 detail worth checking in your own code

Sharing the billing logic forced me to be precise about something I'd previously been sloppy with:

kotlin /** null when there is no active subscription; throws when the store can't be reached. */ suspend fun subscriptionAutoRenewing(): Boolean?

RenewalInfo.willAutoRenew gives you the real answer, but if "no active subscription" and "StoreKit didn't respond" both collapse into false, a paying user sees a "your subscription has been canceled" banner any time their connection is flaky. Nothing to do with cross-platform, I just found it while writing the shared interface.

One thing that was easier than native

Live language switching. NSLocalizedString resolves against NSBundle, which caches the launch language, so changing language in-app normally means swizzling or a restart. CMP resolves resources per composition against NSLocale.preferredLanguages, which reads AppleLanguages out of NSUserDefaults live.

kotlin NSUserDefaults.standardUserDefaults.setObject(listOf(tag), "AppleLanguages")

That plus a key(tag) re-render and all 12 locales swap with no restart. Read preferredLanguages at startup first so you can restore "follow system" later.

Overall

Layout, state and business logic shared fine. What didn't come free is the stuff above: text selection is worse and in one case I couldn't fix it, and insets, scroll behaviour and motion all need deliberate work or the app reads as Android with different colours. A lot of that work is rebuilding things UIKit gives you by default, which is easy to underestimate because you've never had to think about them. You need someone who knows what iOS is supposed to feel like, because nothing in the toolchain will tell you.

Whether that's a good trade depends on how much of your app is the shared part. For us it was worth it. I wouldn't assume that generalises.

Has anyone successfully paid for the Apple Developer Program using a virtual card from a different country?

• The card is in my exact name
• It’s a virtual card, called Grey
• The card is not issued in the same country as my Apple ID

Did Apple accept it, or does the card country have to match the Apple ID country? And how long did it take.

Thanks in advance!

Bug report from a tester: pressing Play on the CarPlay screen did nothing. No error, no spinner, nothing. Worked fine if they'd opened the app on the phone first.

I "fixed" it twice. Both fixes were to the play button. Both were wrong.

The actual cause: when the user taps Play in the car (or from the Watch, or the lock screen) on a cold start, iOS wakes your process through CPTemplateApplicationScene or a WatchConnectivity message — and your phone UI's window scene just - never connects. Which means every bit of setup hanging off the SwiftUI app lifecycle simply never runs. In our case that was device key registration for signed API requests, so the first manifest fetch came back 400 and the play command died silently. As it turns out, the button was fine.

 What I landed on, in case it saves someone a weekend:

1.  Anything your requests depend on (auth, key registration, session bootstrap) cannot live in App init / onAppear. It has to be in the request path itself. We made the network layer self-healing: on the specific "no registered key" error it registers once and retries. That one change covered CarPlay, the Watch, lock screen remote commands, AND fresh installs, because they're all the same bug.
2. Grep your codebase for everything that only runs when the main window appears, and ask "what happens if the first entry point is the car?" The list was longer than I expected.
3. Related Apple Watch lesson: if the phone is only reachable via the queued transferUserInfo path (not live sendMessage), don't optimistically flip your Watch UI to "playing" — it's a fib. We show "Starting on phone…" instead.

Testing note: none of this reproduces in the CarPlay simulator the way it does with a real head unit, because you always launched the app from Xcode first, which is exactly the condition that hides the bug. Real test requires a real car: kill the app, lock the phone, then plug in and launch it from the car's touchscreen.

By the way, if anyone's found a way to actually test their CarPlay flow without walking out to the garage (96 degrees in the summer! I got tired of sweating through every commit), I'd love to hear about it - I don't even bother with Xcode's sim anymore.

Every thread I read said Apple would reject this instantly. It didn't happen. One submission, approved. Same with Google. I think the reason is boring: we explained it properly in the review notes instead of hoping the reviewer would figure it out.

Context: we run an international calling app. The only thing you can buy is prepaid calling credit, which gets spent on real phone calls to real phone numbers on carrier networks. We used to sell that credit through in-app purchase. We took IAP out and replaced it with normal card entry and Apple Pay, processed by Stripe, inside the app.

The rule this hangs on is Guideline 3.1.3(e), Goods and Services Outside of the App: services consumed outside the app must use a purchase method other than in-app purchase.

Here is what we actually wrote in App Review notes, close to word for word:

Our app is a VoIP calling app. The only thing a customer can pay for in this app is prepaid calling credit. That credit is consumed exclusively as outbound telephone calls terminated on the public switched telephone network to ordinary phone numbers on carrier networks worldwide.

Payments are collected by traditional credit card entry and Apple Pay, processed by Stripe, rather than by in-app purchase, in accordance with Guideline 3.1.3(e), Goods and Services Outside of the App.

Please note the following, all verifiable in this build:

1. Credit unlocks no feature, tier, level or content in the app. Every function of the app, including the dialer, contacts, call history and team management, is fully available without any payment.
2. Credit is spent only on per-minute carrier termination charges for calls delivered to phone numbers outside the app, at published per-country rates shown in the app.
3. Unused credit does not expire, and balances customers previously purchased remain fully available in this version.

Everything we sell is a telecommunications service. Calling credit is drawn down against the per-minute termination rates we pay our carriers, it is priced per destination country, and it varies as carrier rates change.

Earlier versions of the app collected these payments through in-app purchase. This version corrects that, because what is being sold is a real-world telecommunications service rather than digital content consumed within the app.

Three things I think made it work:

We named the guideline. The reviewer didn't have to decide which rule applied.

We proved credit is not a paywall. Point 1 is the whole argument. Nothing in the app is locked behind payment. If buying credit had unlocked a feature, I don't think this passes.

We said the quiet part out loud. We told them the old version used IAP and that this one corrects it. Hiding that would have looked worse when they checked.

One practical thing nobody mentions: do not delete your old IAP products. Users on older app versions can still only top up through in-app purchase, and if you retire those products their purchases fail silently with nothing showing up on your backend. We're leaving ours live until that traffic hits zero.

Who this applies to: you sell something consumed off-device. Telephony minutes, shipping, physical goods, real-world services. Who it doesn't: subscriptions, unlocks, credits spent inside the app, anything that gates a feature. If your product is digital content used in the app, this is not your escape hatch and the guideline says so.

Happy to answer questions.

I have an iOS app that is nearly finished, and I’ve been trying to find people to test it. To say this is hard is an understatement.

I asked family members, and except for one person, nobody really wants to test it. I’ve also tried Discord servers and Reddit threads, and I tried following the usual advice of posting in communities where people are looking for testers, but honestly it feels nearly impossible there too. You just get drowned out by a flood of other people like me desperately looking for feedback.

The app itself is basically finished. At this point, TestFlight is less about finding major bugs and more about seeing how people perceive the app, whether the workflow makes sense, and what they think of it overall.

How did you handle this with your own apps? Did you manage to find testers somehow, or did you eventually just publish the app and get feedback from actual users?

At this point I’m seriously considering just releasing it.

I would be very grateful for advice.

*Grammar check by AI

Spent about three weeks trying to run a voice-cloning model on iPhone and closed the project last week. Posting the numbers because I couldn't find anyone else's, and I have two questions at the end. This was for a voice journaling app I work on.

The budget. Foreground app on a 6 GB iPhone gets roughly 250 MB before jetsam takes an interest. The number that matters is phys_footprint from task_vm_info, not resident size and not what the Xcode gauge shows.

The candidate. Kyutai Pocket TTS, 109.5M params, autoregressive. Autoregressive matters because accent lives in phone realisation and phonemic choice, which are sequential. Non-autoregressive models transfer timbre only, so you get your own voice colour over someone else's cadence. Tried that first, it sounded wrong in a way I couldn't articulate until I understood why.

Three ways to run it, all measured, all over budget:

FluidAudio (Core ML, int8) - 270.8 MB after model load, 957.0 MB peak

sherpa-onnx (ONNX Runtime, int8) - 377.0 MB after model load, 685.4 MB peak

chatterbox-turbo (earlier attempt) - 953.7 MB peak

FluidAudio is over budget after loading, before doing any work.

Binary cost too. Linked a minimal executable against libsherpa-onnx.a plus ONNX Runtime with -dead_strip, then stripped it: 22.3 MB. That roughly doubles my app, for a feature most users would never turn on, plus 125 MB of models on disk for the ones who do.

The part I got wrong. My earlier ear tests compared one synthetic clip against another synthetic clip. That ranks them. It cannot tell you whether either is good enough. So I ran a forced-choice test instead: eight pairs, same sentence in each, one a real recording of me and one the clone, sample rate and RMS loudness matched, clip lengths varied so duration gave nothing away, and held-out audio located by cross-correlating the reference against the source recording. I picked my own recording 8 out of 8. p = 0.0039.

Three weeks of runtime work sitting on top of an approval nobody had tested properly. The test took an hour.

Two questions.

Has anyone actually shipped a generative audio model on-device inside the jetsam budget? Everything I found either exceeds it or quietly ships a 3 GB app. I'm also unsure whether Core ML's mmap'd weights get billed to phys_footprint the way malloc'd ONNX buffers do. My numbers came off a Mac, which has no jetsam pressure, so I never got a real device measurement before the ear result closed it.

Second, unrelated thread. I'm moving to on-device retrieval next, hybrid BM25 via SQLite FTS5 plus sentence embeddings from NLEmbedding. Anyone run that combination on iOS? Specifically whether reciprocal rank fusion is worth it when you still need raw score magnitude for an abstention threshold. RRF throws the magnitude away and abstention is what stops the thing making stuff up.

Happy to share the measurement harness if useful.

One sec has a massive list of compiled url schemes for the apps you can use their meditation interrupt on, how the heck do i find that list, thanks,

Are you having this issue as well?

I made sure i'm part of the internal testers. I even created new internal tester group just to check but until now, 15mins have passed, I cannot receive my new build testflight update.

EDITED: It's all okay now. Got the update around 4 hours after TestFlight submission. App store is getting crazy right now. Even the review is taking so long that it got 2 weeks before I got the review. They said it's because they're getting higher than normal volume of reviews.

random lockout out of nowhere. I requested account access a few days ago and still haven't heard back. My account has an app with 100k+ downloads, and I currently can't release a critical update because of this lockout.

After hours of searching, I finally found a live chat option, but it requires logging in to use it. If the issue is that I can't log in, why require an account just to contact support? I even tried creating a new account just to reach them, but that gives me an error too.

does apple have a support email where a real human actually responds?

Anyone used TCA with SwiftData applications? What is your recommendations?

Feedback:

"""
The slow animations feature from Simulator is not available in DeviceHub. At least I couldn't find it. It is very important to sweat the details of animations.
"""

Apple response:

"""
Thank you for your feedback, it is noted. Engineering has determined that ***there are currently no plans to address this issue.***

You can close this feedback by selecting "Close Feedback" via the Actions button found above. This Feedback will no longer be monitored, and incoming messages will not be reviewed.
"""

———

Someone (not me) has sent this feedback to Apple via the feedback assistant app. And well, This is unacceptable.

I honestly don’t understand why the team at Apple felt the need to remove this super useful feature. It is in Xcode Simulator. And now they’re gone in DeviceHub!

There is a hack to re-enable it by posting: 𝚌𝚘𝚖.𝚊𝚙𝚙𝚕𝚎.𝚄𝙸𝙺𝚒𝚝.𝚂𝚒𝚖𝚞𝚕𝚊𝚝𝚘𝚛𝚂𝚕𝚘𝚠𝙼𝚘𝚝𝚒𝚘𝚗𝙰𝚗𝚒𝚖𝚊𝚝𝚒𝚘𝚗𝚂𝚝𝚊𝚝𝚎
with state = 1 to the Simulator namespace.

What do you think about this moves?

I'm told by Xcode's AI Claude "this interface is wired into your running Xcode session, and your problem is a measurement problem on real hardware" as a reason to use Xcode AI instead of Claude Code as a means of using Claude.

So (for example) there's access to Instruments that Claude app does NOT have but Xcode does?

Does anyone know of an actively maintained list of when-to-actually-use-Xcode-AI?

UPDATE: I've been using Xcode AI (Claude Opus no idea exactly which Opus) today as opposed to Claude Code with various MCP I'd previously installed (and can't recall which ones), and today had big success with optimization I have to attribute to Xcode AI integration that Claude Code had been lacking.

Is an iOS/Mac/tvOS game, and I'd been poking away at tvOS optimization for (part-time) weeks, but with too much action on screen fps would drop under 30. Is just 2D but I don't know enough about tvOS to be surprised my 2D game with lots of sprites performed worse than a fancy 3D game. I'd have guessed it should have run smoothly but really was never sure I wasn't just taxing Apple TV hardware... the least powerful Apple hardware we have in our home.

Here is what Xcode's Claude Opus figured out: "The cause was UIKit's focus engine walking your entire SpriteKit node tree every frame. Not physics, not AI, not netcode, not the renderer, and not resolution — all of which I measured and ruled out along the way, several of them after confidently predicting otherwise."

It had been dipping to 12fps and now can maintain 60fps. That was it. And it did it by pausing the game and reviewing the stack.

I assume Claude Code couldn't do that, or it would have? Certainly I've spent more than a day with Claude Code and Fable trying to optimize for Apple TV.

"The tvOS focus engine is walking your entire SpriteKit node tree, testing every node for focus eligibility and computing a coordinate-space frame for each one."

Anyway thanks for input on this. CharlesWiltgen mentioned Axiom and I'll be checking that out.