Pssst, did you read part 1 yet? Great, let’s go…
Several years ago, I was in San Francisco for a conference. At one point, I literally walked into a glass door, forehead first. It hurt like hell.
When I developed my first iOS app in 2011, using Xcode/obj-c, itunesconnect, and Interface Builder, it felt about the same as the glass door experience. Would it be any better this time around?
Let’s have a look at the key requirements for the TapTapMail iOS app:
- A text field where you can write a note and hit send
- A share extension that emails the current content (link or text) from within other apps (Safari, Twitter, Medium, etc.)
Plus, we’ll need to:
- Register the user’s email when the app launches the first time
- Show the registered email on a settings screen
- Unregister the email
The app will need to make API calls to the TapTapMail server, for registration and sending email. Sending email directly from iOS isn’t an option. Apps can open the mail composer, but the user must confirm and send. The extra taps and app switching are what I’m trying to eliminate with TapTapMail.
The process I use for early app development like this is I write just the minimum code to prove I can do it. I write the code in insolation as much as possible (trying out things with CURL, etc). Then, I integrate and refactor it all in subsequent passes.
Proving the basics
One by one, I set about proving I could do each of the following.
- Create a simple iOS app with a text field
- Add a share extension to the app, that can share a tweet from within the Twitter app
- In iOS/Swift, post JSON to an AWS endpoint (nodejs)
Developing in iOS this time around was less painful. Swift is a pleasant enough language, and XCode now automates more of the crufty things like developer profiles and key signing. Interface builder is still a beast, but I was able to make headway while relying heavily on stackoverflow.
After I’d proven I could make those things work, I spent some time coming up with a registration mechanism. This would need to make certain that a user owned the email address they’d be sending to:
- The app collects your email address, and sends it to a
- The register endpoint generates a unique client ID and a random confirmation code. It persists the code, email, and client ID in “pending registrations” bucket. It then sends the 6-digit code to your email address.
- You get the confirmation code in your email and enter it in the app.
- Finally, the app sends the confirmation code to a
confirmendpoint. After verification, the server adds this client to a “registrations” bucket, and returns the client ID to the app.
After a few days, I had a text field in the iOS app where I could type a note, post it to the server, and the server would email it to me.
The iOS/Swift dev environment was tolerable. I know if I did it day-to-day, instead of once every few years, it would be easier.
In part 3, we’ll look at the server.