After a week of working on a side project with a friend, I'm eager to get back to SwiftStarterKits. I have a huge list of things I want to work on, but have been apprehensive in choosing what the immediate top priority items are.
On one hand, I think a company like this needs several sellable products to really provide a value proposition (this sounds naive said aloud). On the other, it likely needs free content and learning resources to make the paid products attractive to buy. Maybe I'm overthinking this and should just focus on value, in whatever form it takes.
I'm thinking of doing a mini-pivot. SwiftStarterKits is still looking to raise the level of abstraction when building apps for Apple's platforms, but will focus on primarily free and open source content. Looking at competitors in this space, there seems to be a large catering towards "app-cloners", which I have no interest in facilitating. By positioning this endeavor as a well rounded kit for quickly getting robust apps to market, it needs a stable and growing knowledge base.
I still yearn to build app templates, components and tools. But there may also be untapped value in the form of guides and documentation. There's tons of documentation that I've written at every single company I've worked for that is generalizable. In the context of "mobile development team operations", there's a heck of a lot of wheels being re-invented as soon as a team gets beyond the 3-4 engineer threshold. I really wish a "scaling a mobile engineering team" playbook existed when I was at my previous companies.
When I say the word "guide", what I mean is something that really details the nitty-gritty of building and shipping apps consistently at scale. A repeatable playbook that lives beyond a programmers tenure. Every company builds up this knowledge base iteratively, what if there was a starter kit for this? A general knowledge template for how building apps work "at this company".
Something that:
- Sets expectations for technical and non-technical teammates on releasing features.
- Provides detailed walkthroughs of how to release the app to the App Store (Every single team needs this to ensure the bus factor is low).
- Documents the maintainance of build automation. Maybe even sub-docs for different CI/CD providers (While Xcode Cloud is a thing, there are still big value props to using a different provider like Bitrise or BuildKite).
- Onboards testers, and describes how to download beta or sandbox builds. Even with documentation, this is a constant source of questions on both small and big teams.
- Gets teammates up to speed on technical interviews. Engineer interviewing is tough, and iOS teams should definitely spend time tailoring offsite/onsite interview rounds to what the team needs both technically and socially. Maybe even a set of take-home projects or interview questions might be useful here?
These are just some of the ideas I've been mulling over, I think they have merit. I'll test them out and see what sticks.
