Eleven days ago, we were about 90 percent finished building the initial version of the DEV iOS app. And then I had a realization: We still had another 90 percent of work to do.
This is a phenomenon so common that it has a name and Wikipedia page: The ninety-ninety rule.
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
Despite feeling like we took a minimal approach from the start, we were slightly off base in the approach and I saw a lot of pain in continuing down that path. So, despite being this close to being finished, we started over.
I made this issue:
Proposal for a modified design direction
#88
I want to propose a design adjustment which simplifies the initial version of this app to be released.
I propose we remove the tabs and lean in on this being an even simpler shell of the mobile web. All navigation will be via the web version of the app.
I'm seeing the last 10% of the existing approach as possibly resulting in another 90% of work. And it's not that we couldn't push it through, but I could foresee it resulting in a sort of maintenance burden we are trying to avoid.
So I think we should go with a stripped down shell that simply offers the web view, with web navigation to everything needed and a bottom bar providing back/forward and other utility buttons (view URL I'm currently on? Open in Safari? Etc.)
We are web focused, we already have all needed functionality on the web. I think we should lean in on a leaner approach and ship something that will at least work as well as the web.
As far as native functionality, I think we should support deep linking, push notifications, and other conveniences, but mostly try to launch something as simple as possible from an implementation perspective, and I think that is what I'm describing.
I know we put in a good deal of work in the current approach, but I don't think we should fall for a sunk cost fallacy. I think we've learned a good deal about what's been difficult, what's been easy, etc.
Final thought: If we go this way, it might be plausible that React Native or Flutter would be a better approach.
And then I spun up a proof of concept.
That proof of concept was basically enough. We went with a simple experience in order to launch a native iOS app. It does make use of some of the niceties of iOS, and importantly does alleviate a few frustrating constraints of only existing in mobile Safari land on iOS. Importantly, it also means that we’ve launched platform to grow from. We have crossed the chasm and can now learn how to provide the ideal native experience.
On Friday we submitted the app to the App Store
We knew that launching quickly rather than living in prototype purgatory was important. What was less obvious was how simple it was to throw out a lot of work and start rewriting the whole app in one night. This was a new one.
Almost all the code for the current app is located in one file, simply titled ViewController.swift.
The night that I realized we needed a shift, I actually began writing three versions of the app. One in Xcode/Swift, one in Flutter, and one in React Native. I also encouraged others to take part in the bakeoff. In this process, the truly native Swift approach always won out for me.
I wrote a bit more about this approach, and I maintain that we made a good call:
I also started a thread about the sunk cost fallacy at play, and got a lot of validating feedback:
Now that we have planted our flag in iOS land, it's time to settle and expand. Beginnings are far less important than middles. We want to quickly transition from this beginning phase to a new period of maintenance and growth.
Happy coding ❤️
Android coming soonish 🤖
Top comments (15)
"What was less obvious was how simple it was to throw out a lot of work and start rewriting the whole app in one night."
WOW. If only more people knew this. It's mind-blowing you guys were able to pull this off. I mean I guess it helps to be run by developers... still. You have no idea how many times I've tried and failed to make this point to clients:
Throwing out work is mentally very difficult. Kudos! I hope the word spreads!
Love the idea to release it early. "rip off the bandaid" as you called it :-)
Congrats! The feedback has been good so far!
About the final approach: a not so hidden plus of having a native shell wrapped around the web app is that improving the web app will improve the native app(s) as well.
This adds a lot of value, "for free".
Exactlyyyyy. I really want to be spending time pouring resources into one great application, which grows in complexity vertically instead of horizontal complexity where we have to reimplement everything over and over again. Over time we will learn the right patterns of sending appropriate messages between web and native.
I actually feel now like we are sort of a browser maker in a sense. We kind of get to think in terms of "what would the ideal single-purpose mobile browser be"? I don't think it's set in stone that you can only benefit from one web browser. We get to build the browser of our dreams to support a web-based experience.
Great story - inspiring approach. Aside: I love swift. I've been trying to shift gears on an app to build in flutter and have ios and android on the same codebase, but it is killing me.
Can you elaborate? It's so interesting, because Flutter seems great in theory but I keep hearing different opinions on it. Not being a mobile developer I'm absorbing such views from people more expert than I am
I think the challenge with flutter is that you have to learn yet another language and approach. For me, someone who sorta slid sideways into development and doesn't spend much time on it, that is just a struggle. I have web applications in javascript, and mobile applications in swift. With both, once I sit down and figure out the requirements, I can logically build the thing that I want to make.
However, Flutter requires you to think differently. Each thing is in a container, and it might not be straightforward to add it.
For example, the other day, I wanted to add a tab bar at the bottom of a mobile application in Flutter. You can't just do that. In swift for iOS, I'd create a tab bar and tell it about the tabs inside of it and all is fine. In Flutter, I had to create a new theme item and nest a bar in it as a child. That is not at all logical. Some things are much easier, though - if you want to add a floating button, that is a big "pain in the constraints" in swift, but it is as easy as adding a floating button to the scaffold in Flutter.
I want to keep trying Flutter because I love the idea. And, developing in Flutter is nice because of the hot reload features. However, the little incongruities really trip me up. I have a feeling that it might be easier for folks coming from a react background.
Thanks Jess, I wonder if Flutter were to be easier for a person that comes from neither React nor a previous mobile experience, such as me :D I still haven't dedicated enough time to it to develop a conscious opinion.
Get started and make an app! There are some great apps you can start playing with here: github.com/Solido/awesome-flutter
This makes me really happy. I used to think native was the way to go, but the web has come so far in those years. It's possible to build a great mobile app without much native code. Normal users won't even notice.
I'm convinced the approach you chose is the approach most companies should choose by default. Even for a company with no iOS expertise, you can spin up an app with minimal Swift, a shared web view to manage a session, and all of your existing web assets.
FWIW, I've had success using Rails, turbolinks-ios, and Stimulus. Happy for you all! I think you have a great foundation here.
Thanks!
What do you think is it that causes the ninety-ninety rule to prove to be true in almost every situation? Is it due to the fact that developers usually handle what they know how to do really well first and leave the rest for 'later'?
That being said, I'm not aware of many professional developers that go by the mentality I suggested there, so what is the root cause of the 90-90 rule? (in your opinion)
I just installed the app and for an experimental release it’s already nice. That 10% should be just 10%
I knew this principle under the name Pareto. Where 80% take 20% of the effort and the 20% remaining eat all 80% time left.
Release at the first 90%, slap on an Early Release/Alpha tag and call it a day. ;)
I may have done something similar...