Spinning a second app out of the first: fork or white label?

In April 2017 we needed a new iOS app for a new brand, a location-based product built around finding spots on a map and getting directions to them. We already had a Swift app with most of the machinery: onboarding, accounts, maps, bookings, push. So instead of starting over or building a white label app, we split it off.

The commit history is a nice record of how that goes.

Two weeks, start to store

April 5: "separating repo." A fresh repository seeded from the existing app.
April 29 to 30: new splash and app icon, Swift 3.1, CocoaPods switched over to the new target.
May 1 to 2: new onboarding screen, colors and themes, branding, new screens.
May 5: the big day. Account flow, routes, text fields, linking the user profile to the API, fixing the default map position.
May 6 to 11: crash fixes, directions debugging, replacing every font, and a run of build number bumps as test builds went out.

About two weeks of focused work to get a rebranded, reworked app into testers' hands. That speed came almost entirely from the decision not to rewrite.

Fork vs. white label app: what forking costs

The trade-off shows up in the file tree. Months later, the new app's source folder was still named after the original app, and so was its Xcode workspace metadata. Renaming a target is cheap; renaming everything that references it is not, so nobody did.

That's fine, as long as you're honest about what you've got: two products sharing an ancestor, not two products sharing code. Fixes in one don't flow to the other. If you expect them to, you want a shared library or a white-label build, which is a different and slower project.

Then, a diet

By late August the app had picked up weight from its ancestor. The commits from August 27th:

"optimizing images and removing video for faster download"
"removing twitterkit"
"removing twitter"
"reducing bundle ipa size"

Inherited code brings inherited dependencies. The app was still carrying a Twitter integration and a video asset it didn't need, adding download size to every install.

The lesson I took: when you fork an app, schedule the cleanup pass on day one, not when someone finally notices the download size. Go through the dependency list and the asset catalog and ask of every entry, "does this product use this?" Every "no" is free download size back.

Would I do it again?

Yes, for the same situation: a new brand, a tight timeline, and an existing app that already solved the hard parts. Starting from working code gets you to a shippable product faster than any template. You just have to remember that you now own everything you copied, including the parts you didn't mean to.