dQ/dT = App Development = dP/dT

For the past few years I’ve been working on…

It’s been quite a ride, learning web-app, mobile-app and back-end/networking. I’ve bought a few computers along the way, I have two web-servers in my room and I’ve probably written over 100,000 lines of Java (Android), Swift (iOS), Python and PHP (back-end). I’ll be launching soon and I expect the production codebase to be close to 20,000.

Knowing this, a close friend of mine that’s planning on undertaking a similar journey recently asked me:

Q1. Got any good resources on iOS development?

I’ll answer this last.

Q2. Reflections on going about learning app development in general?

I don’t subscribe to the MVP model. I don’t think products should be released at a sub-par standard. This is not the same as following an iterative model. I think the “MVP” stage should be internalised because first impressions do matter.

That said, it’s important to internalise the MVP stage in a functional way. Releasing your MVP product to a closed group of informed people that are verifiable and reliable is important for improving your design.

The way I strategised app development was an attempt at emulating Pixar’s filmmaking process. Pixar release hit after hit, in both financial and cultural goals. If you dig into how they make films, you realise they’re unlike any other film studio. Live-action films are handicapped in how they have limited footage and even less resources to manipulate that footage. Animation has the advantage of being able to dramatically edit a shot that’s minimally invasive on the studio.

For “Monsters University” Pixar have released a snippet of 6 different iterations for a scene — https://www.digitalartsonline.co.uk/features/motion-graphics/monsters-university-behind-scenes-from-sketchbook-screen/. If you look into Apple’s design process you find a similar theme — iterations.

In fact, you could argue from the Law of Averages (LA), that the more simulations you offer, the results stabilise and converge towards a fixed number. Whether that fixed number is representative of high-quality or low-quality is a function of craftsmanship, financing and ideology. Nonetheless, if you believe that LA extends to your own design process, then what you’re saying is that the more you iterate, the closer you approach the right result.

With this established, my answer to learning app development is simple — time. It’s not about learning app development, it’s about being able to deliver high-quality apps. If your business depends on an app then the answer is obvious — you need high-quality.

In “Running the War in Iraq” by an Australian general that served in the Second Iraq War, Major General Jim Molan recounts a mantra the US Marines’ Headquarters followed:

“Slow is smooth, and smooth is fast”.

At the end of the day, it’s not what you know — it’s what you can deliver.

Q3. Would you start with iOS or Android first?

If you were learning app development from a hobbyist perspective then I’d say it depends on whether you know Java (then Android) or Swift/Objective-C (then iOS).

Otherwise, and what the more likelier scenario is, you’re learning app development so you can deliver a product. In this case, figure out what your market is going to be most responsive to. Then learn the respective framework.

Q4. What methods did you find gave the greatest reward for time when learning in the beginning?

Focus on your goal — you want to build an app. You don’t know how, so you need to learn.

Assuming you have previous programming experience, the key pain point relates to syntax and understanding app architecture. The fastest way to resolve these is to find a tutorial that achieves the following: explains causation, is broad in ambition, highlights limitations of their own code, and goes through debugging (usually at the expense of a concise video). Only watch a few and make sure each one is different in objective. What you’re doing is building a compact library you can reference when you encounter your own issues in the future so they can guide you in resolving them.

Learning how to take it as it comes is an art.

Once you have an intuitive sense of how the app works and not necessarily, an intuition on how the app explicitly functions, then I’d recommend start building your app. You’ll fill in the gaps by building the app yourself and adhering to a long-term iterative process that’ll allow you to achieve two key things:

1. Improved technical performance,

2. Refined design

Q5. How did you go about designing architecture, what advice did you take?

Diving in the deep end means you really don’t know what you don’t know. Ensuring you don’t fall victim to the Dunning-Kruger effect, you need to constantly remind yourself about this deficit.

It’s also important to consider such blindspots reside in all communities, following an inverted exponential graph (x-axis: level of sophistication, y-axis: strength of blindspots affecting progress). This means — don’t listen to amateurs. Be selective in who you listen to and in general, it’s better to listen to the proven than to the unproven. History holds a lot of your answers.

Being able to identify proven/unproven can be difficult in online communities and this can only come with experience (if you’re teaching yourself). So expect wrong-turns and downfalls, but they’re only local minimums in a function with a positive gradient.

With this in mind, designing architecture was pretty simple — I came across MVC architecture (something we weren’t taught in 3 subjects of programming???) which has proven to be really important for client-side code.

If you plan on developing a back-end service (most likely) and you’re unfamiliar with these process, then you’re basically going to experience app-development round 2. What I mean by that, is it’s an entirely different process and in general, it’s more conceptual than a technically heavy one thanks to cloud computing services (GCP/AWS).

In closing, app development is incredibly technical and unlike any other type of programming I had come across before. There’s a lot to learn, especially if you haven’t had much graphics experience (your’s truly) and even more so if you haven’t had any back-end experience. There’s plenty of resources online, but the best way to learn is by building it bit-by-bit and not being afraid to rebuild whenever you think it’s sub-par.

The most consequential decision you have to make now is whether you’re going to internalise the MVP process and accept:

App development = dQuality/dTime

Or, you’re going to publicise your MVP:

App development = dProgress/dTime

Back to Q1: Got any good resources on iOS development?

It should be obvious by now that when you’re learning, most of the resources you come across today will be redundant tomorrow because you’re constantly filling in the blanks with what you don’t know.

Dive into the deep-end and you’ll find how shallow it really is.