For the last few months, I’ve worked on Gigglebot, an iOS app for instantly putting AI images in your text messages. Starting with no experience in Swift or iOS app development, it’s been a huge learning experience, and I wanted to share some of the insights I’ve learned along the way. Because I wasn’t familiar with Swift, I relied heavily on Cursor and ChatGPT to help develop this.
General project/product management
- The gap between an initial MVP and a release-ready product is huge, as it requires appropriate secret management, subscription/payment management, and cross-device user authentication. If you are developing a server-connected app, add additional layers of authentication, security, database models, and admin controls.
- Things take twice as long as you expect- when you know the platform well. If developing in a new language, expect that to be more like 4-6x longer than expected. I hoped to have my app done in 4-6 weeks; it took 4 months.
iOS design
- I developed for iOS in Swift, something I’d never done before. Coming from Python, expect to learn a lot about closures, async operations, and static typing, as well as GUI layout elements.
- Apple’s documentation has far fewer examples than I was expecting, particularly for iOS features which aren’t part of the central UI. This can include iMessage Extensions, ARKit, Storekit, or other tools. Some of these (e.g. iMessage Extensions) have really languished for lack of attention and may have surprising bugs
- Some functionalities are not available in the XCode Simulator or an XCode build deployed directly to your phone/tablet, and cannot be debugged accurately without deploying through Testflight. I’ve run into this with some Storekit functionality (especially receipt validation and transaction id information) as well as geospatial ARKit functionality (from my CityScaper project). This is infuriating, as logs are not available when you’re working with a deployment through Testflight.
- If you want some form of cross-device or cross-platform validation, it’s easiest to use emails or an OAuth/JWT provider. There are more elegant ways of managing this, but they take a lot more work, and right now they aren’t easily implemented. production
Monetization
- The current monetization trend is to offer a free download with in-app subscription purchases. There is great tooling for creating recurring revenue through subscriptions and paywalled services (Superwall, RevenueCat). Building for in-app consumables (tokens, credits) or freemium systems is much harder and less well-supported.
- The best support is for a standard flow for validating Storekit2 entitlements, which works well for subscriptions and in-app non-consumable purchases, and is demonstrated in the excellent “CaffeinePal” tutorial by Superwall here. If you can, stick to this: it’s the canonical and headache-free way of managing in-app purchases.
- In-app referral programs cannot be rewarded with any products which are also available for purchase (credits/tokens/membership). You need to differentiate rewards- e.g. by having referral rewards expire (my use case). Apple is very concerned about anything which could circumvent the App Store revenue cut for in-app purchases.
- Apple has a legacy “App Promo Code” system for apps which are pay-to-download (allowing you to give away a limited number of free downloads through an App Store code), and a much better-supported Offer Codes system which are only valid for subscriptions and are set up in App Store Connect for subscriptions.
iOS App Store setup
- If you’re expecting to take investor money or get acquired, you want to have your product held by a corporate account, which requires extra steps which could cost you ~4 weeks:
- Incorporate your company (I used Clerky.com): ~1 week
- Set up a corporate email account (I used Google Workspace) and company website: ~1 day
- Get a virtual mailbox to use as your Dunn & Bradstreet address, which will be visible for your app in EU countries (I used Anytime Mailbox)
- Get a Dunn & Bradstreet DUNS number through the special Apple iOS development program linked in the “lookup” flow on this page. Use the Apple developer link for faster service (mine took 8 days).
- Get a corporate bank account set up: 1 week, can be parallelized with DUNS setup
- Create a corporate Apple ID. This required calling Apple to unlock an authorization step for me, which was a puzzling surprise.
- You can’t transfer a pre-release app to another (corporate) account- you can only transfer after you release the app. If you want to have the app tied to your corporate bank account at the time of release, you’ll need to either develop the app from your corporate account from the start, or remove your app from App Store Connect in your personal account, change the Bundle ID, and then re-upload it with a new Bundle ID from your corporate account.
App Store listing
- If you’re planning on running the app as a business, you’re a “trader” under the EU Digital Services Act- ultimately, this will require that your Dunn & Bradstreet business address gets piped to the App Store listing for EU countries (not visible in the US). If you want to preserve privacy, get a virtual mailbox or virtual office (or a real office) and make sure your listing is up-to-date.
- I shopped around and decided to go with AppScreens for app previews, and Canva for video editing. AppScreens handles resizing your layouts to the appropriate size for iPad, though if you have a better-defined workflow I suspect that Inkscape scripting could do a good job.
- Capturing screen recordings through
- If you have an iPad version of your app, you have to make sure that app screenshots are taken from an iPad.
- App Previews must primarily consist of a full-size screen recording, without any framing or design outside the app preview. Overlay text is passable if used in moderation. Apple’s guidance here is cryptic, but my experience is that App Previews that have too many outside design elements or which utilize elaborate transitions will get rejected. TikTok is a great example of how a team worked very creatively within their app’s framework to show a screen recording which is so engaging you forget that the recording still has all the edit/interact controls.
- No fun emojis or ascii art in your app description, sorry 😢
The things you build along the way
I built a bunch of tooling which is helpful in its own right; if I weren’t focused on getting this out the door I may try to turn these into micro-SaaS companies of their own right:
- Creating angled-perspective photogrids such as those used for gigglebot.app and the in-app paywalls
- Creating dummy/placeholder app icons when working on test/debug apps before you have an icon design
- Exporting app icon PNGs from SVG for all the many different sizes required for iMessage Extensions
- ffmpeg shell scripts for editing screen recording videos
It’s been a long journey, but a fun one!