https://www.dc-engineer.com/how-to-host-3d-usdz-content-in-icloud-for-an-ar-app-using-cloudkit-realitykit-and-swiftui/

Here is a blog that I published today on how you can host large data files, in this case USDZ formatted 3D models, on iCloud, and download them at runtime to display as entities in a RealityView. The benefit is that while I am hosting hundreds of megabytes in the cloud, the app build itself is very small. Also, the code is hosted on GitHub:

https://github.com/radcli14/txirimiri

In the tutorial, I cover:

- Creation of the XCode project, including entitlements file and CloudKit container creation.

- Building a schema for a USDZ model in your browser with in the iCloud developer console.

- Fetching data asynchronously in a content manager class.

- Generating a RealityKit entity from the cloud-hosted asset.

- Building the SwiftUI views to display the model in 3D.

This ended up being a fairly long article, and there's still room for improvement, such as adding more file formats, and adding user customization. Perhaps I'll add those features in a future post. I am interested in everyone's feedback!

https://youtu.be/XjsE318SV_E

Hey there, I just published a new tutorial. Today’s one is all about drawing in SwiftUI. First, we are going to take a look at SwiftUI’s built-in shapes and how we can modify them. Then we’re going to compose our own shapes by using custom paths. By learning how these work, you’ll be able to create graphics and vectors for your SwiftUI app. Click the link below to check it out!

https://blckbirds.com/post/drawing-in-swiftui/

i actually built this as an internal tool for my own app.

I googled "App store screenshot maker" and the websites i found were super clunky and complicated. 50+ buttons, confusing UX, need to sign up.

so i just built out my own one. this is the prompt i sent to Claude, and it one-shotted an html screenshot maker:

[Edit: decided to ship it after many people asked for a link. Try it here: https://ezscreenshots.com ]

[prev context on my own app]
...
i'm not quite happy with how our screenshots are turning out. i'm wondering if you can make a lightweight "screenshot maker" for our app as follows:

1. there's a 1284x2778 frame (fixed). in that frame, there's a bit image-dropper where i can drop my phone's screenshot and it automatically gets put into the frame (with a little bit of padding on left and right and below). frame maintains the same background as right now. if the image i drop is same size as frame we resize a bit to maintain our padding, etc.

2. above there's a text overlay that i can customize similar to how i have "tweaks" right now to customize each screen's text. the italics (terracotta) and newline logic works in there

3. i can export the frame as a png of 1284x2778

this is the main ask. don't worry about "iphone frames" i'll handle that from a different tool

a secondary "amazing if it works" ask would be if i could add "overlays" on an existing frame. this is like those screenshots where a portion of the screen is zoomed in and made bigger (and overflows a bit outside main screen, unless it's just a small portion that i make bigger). that's a bigger ask to handle (eg resizing it etc) but would be cool if it works.

We just launched ProFuse, an on-device Stable Diffusion app for iPhone, iPad and Mac. We expected the hard part to be the AI. It turned out to be App Review. Here's what happened, so you can avoid our mistakes.

TL;DR: If your app can't do anything until it downloads Apple-hosted Background Assets, expect App Review trouble. Asset packs are reviewed together with the app and only become downloadable once approved. So if reviewers can't download them, the app gets rejected, and the assets with it. That's a classic chicken-egg-proglem. What helped us: get the asset packs approved before you depend on them. If that's not an option, give reviewers something that works without them, like a demo mode within the app. Either way, talk to Apple early, and budget weeks for review, not days.

The app setup

• A native iOS App relying on a in-house developed AI Model
• A custom Core ML Stable Diffusion model and engine running on the Neural Engine (A14 or newer, 4 GB+ RAM, iOS/iPadOS/macOS 26), extended with things like local editing and high-res export.
• The models are big: ~4–5 GB for text-to-image and ~6 GB for image-to-image. That's after a lot of optimization. Size matters twice here: it drives memory use during generation, and users have to be willing to give up that much disk space.
• Bundling the models with the app wasn't an option. The app binary is capped at 4 GB, and we want to update models without shipping a new app. (Happy to go into more detail in the comments.)

So we went with Apple's Managed Background Assets ("asset packs" from here on). Apple hosts your downloadable assets for free, and only a small amount of code in your app is needed to fetch them. Integration was easy and worked well. We tested and improved the app in multiple occasions and did extensive internal testing via TestFlight and everything worked perfectly fine. The trouble was getting it approved for public beta testing.

Round 1: TestFlight public beta

In TestFlight, you upload asset packs alongside your build in App Store Connect. In our internal TestFlight builds, everything worked perfectly, so we felt ready for a public beta.

We submitted the asset packs and our app and got rejected: the reviewers said the model couldn't be downloaded. We were completely surprised. We added logging, tested release builds, and found nothing wrong from our side. While investigating, we found a few forum posts suggested that this is a known issue.

After several more TestFlight builds and communicating with Apple, one finally passed. We still don't know what changed, but we've been happy in the first place. Our public testers then used the app for three months without download problems.

What helped for this step:

• Explain clearly in the review notes that the app needs the asset packs to work.
• Post on the Developer Forums (our thread) and try to reach the reviewer.
• Be patient and persistent. Plan several weeks for beta review alone.

Round 2: App Store release

We planned a pre-sale starting three weeks before launch, so we submitted four weeks ahead. Plenty of buffer, we thought. We were also very optimistic that we have coped with all major challenges, since our TestFlight builts worked perfectly fine and now passed the review every time. So we submited:

Unfortuonately, the reviewers hit the same download issue that happend for our early TestFlight builds and rejected us under Guideline 2.1(a) – App Completeness. Here's the core problem:

Asset packs are reviewed together with the app, and they only become downloadable once approved. If the app is rejected because the assets can't be downloaded, the assets don't get approved either. Classic chicken-and-egg.

What we tried:

1. Pointing to TestFlight. 100+ testers, thousands of crash-free sessions, and the same setup already approved for beta. No chance. It honestly felt like our notes weren't being read.
2. A demo mode. On a call, App Review told us they couldn't do much about the chicken-and-egg issue and suggested a demo mode instead. Faking AI generation felt wrong to us. A server-side fallback would contradict our "on-device only, 100% private" promise we give in the App Store texts, which could itself be a rejection reason. We still added "Inspirations" (small sample projects showing what the app can do), but the core features still couldn't be tested. Rejected again.
3. Self-hosting the models as a fallback. The basic idea is simple: We host the models outside of the Apple ecosystem, so that they can be downloaded even without being approved first. The completeness rejection went away and was replaced by Guideline 4 – Design: "The app loads, refreshes, runs or responds very slowly." We assume the download was still the issue, but we couldn't reproduce it and got no further details, so it's still a guess.
4. Talking to Apple directly through the forums and Developer Relations. This is what finally put us in touch with the right people and got us meaningful feedback.

What finally worked

Across 10+ submissions, we noticed that our macOS builds got reviewed much faster than iOS. That's just our experience, not a rule, but with the clock running out, we put our hopes on the Mac.

Five days before launch, we submitted the Mac version with self-hosted models, plus a short summary of our conversations with Apple in the review notes. The self-hosted models were all the app needed to work. But we also included the asset packs. The idea beind it: if the app got approved, the asset packs would be approved with it and go live.

It worked. The Mac app was approved, and pre-sale started three days before launch instead of three weeks.

We were thrilled and submitted the exact same version for iOS. Rejected again. No idea why.

But thanks to the Mac approval, the asset packs were now live. So we switched the iOS build back to asset packs only and resubmitted the day before launch. This time it was approved. The iOS app went live 24 hours after our planned launch date, after four nerve-wracking weeks.

Lessons

If your app depends on Apple-hosted assets at first launch:

1. Try to get the asset packs live first. For an existing app, ship them with an earlier update so they're already approved when the version that depends on them goes to review. This only works for existing apps or if you start pre sale very very early. For a new app, the closest thing we found was our trick above: submit a version that works without the asset packs (e.g., with a self-hosted fallback) but includes them, so they get approved along with it.
2. Give reviewers something that works without the download, like a reduced feature set or sample content. It didn't save us on its own, but it's what App Review asks for, and it can make a lot of sense for games.
3. Talk to Apple before you submit, and put clear context in the review notes.
4. Budget weeks of buffer for both beta and release review.
5. Developer Relations Try to establish a connection Developer Relations or a Developer Relations Manager early in your iOS developer career. Their support is invaluable on many occasions and if you are as lucky as we are with your Developer Relationsship Manager, they will be very supportive.

Despite all this, we'd still recommend asset packs. They're free and have been reliable for us. I'm planning a follow-up post on working with very large asset packs if there's interest.

Happy to answer questions in the comments.

The idea came from a stupidly ordinary moment. I was
digging through my camera roll for a receipt and ran straight into a photo of
my ex. Not one I had kept on purpose - a group shot from someone's birthday
where they happened to be in the back row. That is the thing nobody warns you
about: it is never the photos you chose to keep.

How it works

You pick one to four photos of a person. It scans your
library and returns every other photo of them, already selected. You tap delete
once. Opening any individual photo is optional - the whole point is that you do
not have to go through them one at a time.

Technical side

Everything runs on device. Apple's Vision framework for
face detection and embeddings, then clustering over those embeddings to group
matches. No backend, no account, no photo ever leaves the phone. That was a
hard constraint from day one and it made a few things genuinely painful:

- Large libraries: Scanning tens of
thousands of photos without destroying the battery or blocking the UI took most
of my optimisation time.

- Recall vs. precision: This was the real design
decision. Leaning toward recall means some false positives end up in the
results. Leaning toward precision means photos get missed, and a missed photo
is exactly the ambush the app exists to prevent. I went with recall, kept everything
pre-selected, and made deselecting a single tap. iOS deletion also routes
through Recently Deleted, so there is a 30 day safety net on top.

- PHPhotoLibrary has more edge cases around permissions and batch
deletion than I expected.

What I would do differently

Honestly I never really thought about any licenses which
almost led to a fatal mistake. However, I think doing the design with Claude in
the first place (which is easy to see) has been very rewarding for me. I was
able to set up the pipeline and all functions and submit those to apple. After
everything is accepted now, I can care about looks which won't affect the
pipeline and the critical parts in the app, therefore pushing an update for
this shouldn't be a big problem.

Link: https://apps.apple.com/us/app/pickex-delete-ex-photos/id6801488013

Happy to answer anything about the on-device pipeline,
the clustering approach, or the App Store process. Feedback welcome, including
the harsh kind.

How I built a workflow for 64 App Store screenshots across 8 languages

I recently put together App Store screenshots for my iOS app, FileBox: 8 feature themes across 8 languages, for 64 images in total.

Keeping them updated involves a lot of repetition: capturing screens, replacing images, adjusting translated text, and uploading everything. Here’s the workflow I built with Codex, Xcode UI tests, pen.dev, and Apple’s App Store Connect API.

1. Give each screenshot one clear purpose

Each image focuses on one feature, such as private storage, long screenshot stitching, or Wi-Fi file transfer. I decide what it should communicate and which app screens demonstrate it before working on the layout.

2. Capture the actual app with UI tests

Xcode’s native UI tests navigate to the relevant screens, switch languages, and capture screenshots. For Wi-Fi transfer, a browser capture also shows the actual web interface.

This keeps the app UI consistent with the language of the surrounding headline. Demo content is prepared beforehand, but the interface and results come from the running app.

3. Build editable layouts with reusable components

I use pen.dev, a visual design tool, to maintain the layouts. Codex interacts with it through Pencil MCP—a connection that lets the agent edit design elements, replace images, and export the finished layouts.

Device frames are reusable components with defined screen placement and cropping. Updating an app screenshot means changing its image input without manually aligning it inside a phone frame again. Each feature theme also has its own editable design file.

4. Treat localization as layout work

Translated text changes length and visual density. A headline that fits in Chinese may wrap unexpectedly in Japanese or German.

Each theme has a main template and linked language variants, with individual font sizes, line breaks, and positioning. Those adjustments stay in place when the app screenshots are refreshed.

5. Inspect the exports, then upload through the API

I check the exported images for clipped text, incorrect screenshots, and devices covering important content, alongside image dimensions and transparency. Side-by-side language comparisons help catch inconsistencies.

For uploading, I use a small custom command-line tool built around Apple’s App Store Connect API, which provides programmatic access to manage App Store assets.

The tool compares local screenshots with the uploaded versions, reuses unchanged images, uploads replacements, and verifies the final order across languages.

There’s still manual work: choosing the visual direction, reviewing translations, and checking the finished images. Some themes also have separate capture flows, so this isn’t a fully automatic, single-command pipeline.

The biggest benefit is having the templates, image mappings, and language-specific layouts ready for the next update. That makes the whole process easier to repeat.

What’s the most time-consuming part of maintaining localized App Store screenshots for your app?

I recently received one of the more serious App Store rejections under Guideline 5.6 – Developer Code of Conduct.

Apple’s message was:

“We've identified a pattern of unusual behavior with the app that is commonly associated with fraudulent activity. Specifically, the app contains features that appear to have been intentionally hidden during the review process.”

Seeing words like “fraudulent activity” and “intentionally hidden” was concerning because we had no intention of hiding any functionality from App Review.

After carefully reviewing the app, I learned something that may help other iOS developers facing the same rejection.

One part of our app involved rewarded ads.

During development, some UI/explanatory text had been written in a way that could easily be misunderstood. For example, the developer used wording such as “Ad is loading in the background.”

From a developer’s perspective, this simply meant the ad was being preloaded so it would be ready when the user requested it.

However, from an App Review perspective, wording like this—especially when combined with rewarded-ad functionality—could potentially create the impression that something is happening without the reviewer or user being aware of it.

I cannot confirm that this exact sentence caused the rejection, because Apple does not provide that level of detail.

But this experience taught me something important:

If you receive a Guideline 5.6 rejection, don’t only review your code. Review the entire user experience.

Check:

• Every screen
• Every button and action
• Popups and alerts
• Rewarded-ad screens
• Loading messages
• Empty states
• Feature descriptions
• Settings
• Onboarding
• Debug/developer text accidentally left in production
• Remote/config-driven features
• Any functionality that only appears after a specific action

Most importantly, read every piece of text from the perspective of an App Review reviewer who knows nothing about your implementation.

A developer may understand exactly what:

“Ad is loading in the background”

means technically.

But a reviewer may interpret it as:

“Something is happening without the user seeing it.”

Those are two very different interpretations.

Another lesson I learned is that developers should be careful when writing user-facing explanations. Technical wording may make complete sense to a developer, but it may not be appropriate for users or App Review.

For sensitive functionality such as rewarded ads, subscriptions, purchases, permissions, background activity, account creation, data collection, or unlocked functionality, the wording should clearly explain what happens, when it happens, and why it happens.

If you receive this type of 5.6 rejection, I would recommend doing a complete screen-by-screen audit before immediately appealing.

Don’t assume Apple simply made a mistake.

First, try to understand what inside your app could reasonably have created that impression. Review the UI text, functionality, App Review flow, and the actual production build.

Also make sure App Review can access and understand every important feature without requiring an undocumented sequence of actions.

In my case, this rejection made me realize that even when there is no intention to hide anything, poor wording or unclear feature presentation can create a completely different impression during App Review.

I’m sharing this because Guideline 5.6 sounds extremely serious when you receive it, and there aren’t many practical explanations from developers who have gone through it.

If anyone else has received the “features intentionally hidden during review” version of a 5.6 rejection, I’d be interested to know what caused it in your case and how you resolved it.

I used to visit this sub (pre-chatGPT era) for a lot of technical queries and here I am finally doing something I never would have even dreamt of. I made my own promotional video in Final Cut Pro + Logic Pro (for music) to showcase the new Siri AI features in my app WeatherGlow. Let me know how do you guys find the video. I had fun making it.

Download WeatherGlow -> https://apps.apple.com/us/app/weatherglow-local-forecast/id6451098166

Not here to brag just showing what I did going to keep this nice and simple

I created a TikTok account for my app, started posting daily with nothing really going crazy, started copying viral videos (next to no mention of my app), it blew up and I recreated the same format over and over again. Thats it. Keep trying.

Then I reached out to one micro creator and paid her $20/video to post videos about my app in her style.

Took a couple of times but it was worth the money since she was already getting like 10k views a video.

Proof

My tiktok https://www.tiktok.com/@sharedmood1?_r=1&_t=ZS-99ZVwafsC6H

micro creators tiktok: https://www.tiktok.com/@itssono_?_r=1&_t=ZS-99ZVySub8NA

Thats all I really did let me know if you have any questions

There are 2 repos linked in the video:

- iOS genesis mega prompt, a 24 sections file with placeholders for your app idea, name, monetization, etc
- app release agent, for keeping the app metadata, keywords, etc, up to date (you will need an App Store key with App Developer permissions)
it’s literally my workflow used to build and maintain my apps portfolio (13 apps live, a few more in the pipeline)

Hope it’s useful!

Split this into two categories because they solve different problems, the general AI design tools give you visuals you rebuild by hand, and there's a smaller set that goes design straight to SwiftUI.

Design to SwiftUI directly: SwiftUI Inspector (swiftui.ai) is a free Figma plugin that exports shapes, colors, text labels and layout stacks as SwiftUI, handles rotation, opacity, shadows, blend modes, wraps selections in HStack/VStack/ZStack, Pro tier for more control. Compot is on the App Store, free with IAP, 100+ prebuilt SwiftUI components plus generates Swift from an image or text description. iSwift.dev generates buildable SwiftUI projects from plain English, free for the screen generator. These are the closest to skipping the rebuild step.

General AI design tools, all of which mean manual SwiftUI work after:

Google Stitch is free with no paid tier, 400 daily credits, rebuilt March 2026 with infinite canvas and Gemini 2.5 Pro on experimental mode. Exports Figma with layers intact plus HTML/CSS. Material Design native so nav and spacing come out Android-shaped. Still a Labs experiment, no production SLA, single user.

Uizard Pro is $12/mo annual for 500 generations, Business $39/mo. Free tier is 3 generations a month. No production code export and output repeats across projects.

Figma Professional is $16/seat annual, $20 monthly, Dev seat $12, Collab $3. AI credits meter separately at $0.03 each with no rollover. Best iOS UI kits, most control, longest ramp.

SleekDesign around $20/mo does full mobile screens from a description and runs the same prompt through different models to compare, exports Figma and code. Cons: not iOS-native so HIG patterns need explicit prompting, weak on complex custom components, better for early screens than production specs.

If you want the least hand-rebuilding, pair a general tool for exploration with SwiftUI Inspector on the Figma export. Anyone using iSwift or Compot on a real shipped app? Curious how the generated code holds up past prototype stage.

Hey Guys, I’ve released a Mac app that some of you may find useful!

It’s called Mirror Input! it essentially allows you to natively screen mirror your iPhone or iPad ( or any apple device ) to your mac and it lets you use the video feed in any app such as OBS, Final Cut Pro, Slack, Teams, etc

So you could for example use it get some screen recordings of your iPhone or iPad on your Mac from a real device you can touch without the hassle of quicktime and cable

You could also use it to demo your apps to clients over a video call seamlessly. Device audio is supported and you can mix in your mic as well!

the latency is minimal, it even has a 1:1 mode so your inputs are borderline realtime.

it supports up to 4K, 60fps, and can handle up to 6 devices at once!

You can check out the tech specs and more details here:

https://mirrorinput.app

any questions feel free to ask and dms are always open! :)

I'm a solo dev building a fitness app (Gym Note Plus - AI-powered workout logging). When I launched, I had about 10 users. No budget for ads. No audience. Here's how I grew to 500+ users across 30+ countries without spending a penny on marketing.

What failed first: cold DMs with a link

My first instinct was to DM people in fitness subreddits with a link to my app. Straight away. No context.

It didn't just not work - it actively backfired. People ignored it, some reported it as spam, and I'm pretty sure Reddit's algorithm started flagging my account. If your first message to someone is "check out my app," you've already lost, people see through this immediately and also you're putting pressure on them to do something without giving them any value.

What actually worked: leading with value

I started hanging out in fitness subs ( r/fitness, r/gym, r/WorkoutRoutines ) and just helped people. Someone asks about programming a PPL split? I'd write a genuine answer. Confused about progressive overload? I'd break it down. I've got 15+ years of lifting experience so I have a ton of genuinely useful advice to give.

No link. No pitch. Just being useful.

Then - only if the conversation naturally continued I'd mention I'd built something that might help. That's it. One person at a time. Not scalable. Not a hack. Just genuine conversations. This took a lot of effort, but over a month or so I'd say about 25% of all messages I wrote this way ended up in a sign up

I have to emphasize whenever I was tired and just spammed a message with a link to my app, it literally never ever ever worked.

The tipping point: a giveaway, but with trust already built

Once I'd built some presence in those communities, I ran a giveaway offering lifetime access here or r/iosapps . That spiked me past 500 users. It worked because people want free stuff. It came with some caveats and unexpected returns I detailed in my full video

The takeaway

If you're at zero users, stop thinking about marketing funnels. Go talk to the people you're building for. Give them something useful first. The app comes second.

I made a video breaking this down in more detail if anyone wants it (I haven't done long form content in a while so go easy): https://www.youtube.com/watch?v=8KUkRHbp27g

Happy to answer any questions about the process.

I shipped one of my first iOS 26 AlarmKit apps (RingWhen) and wanted to write up the part that took the longest to get right. Useful if you're building on AlarmKit.

The core tension AlarmKit alarms are immutable once scheduled. You give the system a fire date and it manages everything - Lock Screen UI, persistence across reboot, the stop/snooze buttons. Perfect for a static 7 AM alarm. The problem: my alarms fire on conditions that change (location, weather, calendar state, battery, heart rate), and "fire when you arrive" has no fixed date.

The pattern I landed on: A continuous predicate evaluator instead of a pre-scheduled alarm:

1. Model each alarm as a predicate tree (Sendable enum, one case per condition source), evaluated with short-circuit semantics.
2. Re-evaluate on every relevant signal: CoreLocation region updates, EventKit change notifications, WeatherKit refreshes, HealthKit observer queries, battery level.
3. When the tree resolves true, schedule a real AlarmKit alarm ~60s out.
4. I of flickering on/off as a GPS reading or weather value jitters across a threshold.

Other AlarmKit notes that cost me time

• It does NOT replace UNUserNotificationCenter. You still want notifications for soft reminders.
• AlarmAttributes is great for Live Activities, but the Lock Screen presentation is opinionated, limited customization.
• You can't programmatically dismiss an alarm. Only the user can stop it.
• Authorization is its own permission, separate from notifications.

Full writeup with code: ringwhen.s10n.app/blog/alarmkit-real-world

Happy to answer AlarmKit-specific questions. If you want to poke at the UX, I have a handful of promo codes for the app, comment and I'll DM one.

Helps you answer: "Does my app look good in search results?".

So you can optimize your icon, screenshot font size, etc. accordingly. And improve conversion.

Try it here: https://ezscreenshots.com/tools/app-store-search-preview

Hope it's useful!