iOS for Web Developers: Building Permeate

Permeate iOS app →

Intro

I've been a web developer for 4 and a bit years now, primarily using JavaScript & Node.js to build web apps. This was my first foray into the native world. I thought I'd share my experiences of approaching iOS from a web background. I certainly wouldn't class this as a tutorial of sorts, as my knowledge is going to be minimal after just one app, but if you do learn something as a result of reading this; then that's swell.

I've been in the web world for a little while now, so I know the people to talk to, the sites to visit and the blogs to read. However, I feel like I'm starting all over again with iOS, so if any iOS people do read this, your wisdom and advice would be greatly received.

Resources

I always see posts where the resources are at the end of the post, but I thought I'd save you the trouble of listening to me waffle on and just put them first.

So, without further adieu (some are quite specific to Permeate's functionality, some are more generic iOS ones):

Tutorials

• Loading and Caching Images Asynchronously on UITableView
• iOS 6 and the Social Framework: Twitter Requests
• Blocks and Table View Cells on iOS
• API requests with SLRequest
• Design Then Code: Building iOS Apps From Scratch

Sites/posts with great resources

• Treehouse (ignore the dodgy marketing, the content is ace)
• Code Tutsplus
• On learning Ruby Motion versus Objective C & Xcode
• Ray Wenderlich

Tools/cheatsheets/code

• RGB Syntax Conversion
• The iOS 7 Design Cheat Sheet
• App Icon Template
• Standard iPhone Element Sizes (Width x Height)
• iOS Code Examples
• Objective-C cheatsheet
• SSToolkit

I tend to keep my Kippt iOS list up to date with anything I find around the web, so feel free to keep an eye there.

Why Permeate?

Permeate, apart from iHi.im is the simplest product I've made. It has two views. A "log in/connect to Twitter" view and a timeline view. A lot of people commented on the web app and said it would work better as an app, which I do admit, it does. A lot of people want the "web to win" in the colossal and endless battle between web and native. What are we trying to win? I'm primarily a web developer and enjoy developing for the web a lot. The ecosystem is vast and things move very fast. The community is thriving and information is everywhere. However, it's fragmented. There are 3 or 4 different ways to do stuff on the web, depending on which forum/blog post you read. It seems that the web community would rather build a new tool or language to achieve a goal or fix a problem than to massage current tools and nurture existing technologies for the better. The native world seems to move at a slower, more thorough rate. The quality is higher, as the barrier to entry is higher. It seems that the web community scatters itself into cliques and wages wars in GitHub issue threads and Hacker News comments. I noticed a lot more singularity and unison in iOS. Maybe that's because Apple control everything in their "walled-garden", but hey, it's a nice garden.

Some things work better as apps that people can download. I like that. There's no war. No battle. No-one has to subscribe to the One True Way™. Native was personally a breath of fresh air after being in the messy landscape of the web for a while.

So, onwards.

Tooling

I'm never been a massive fan of IDE's for development, I think that stems from bad memories of Visual Studio for Visual Basic and Netbeans for Java; huge, bloated and slow. Overkill for web development if you ask me. Hence why I stick with glorified text editors (Sublime Text 2) for stuff like Node and JavaScript. However, this is Apple. And whilst iTunes is one of the most hormonal programs I've ever used, Xcode really is a coding delight. People often joke about Objective-C having verbose syntax, which it does (will delve into this further down), but using Xcode's autocomplete feature, I don't think I typed out one method name in the entire app.

Storyboards let you visually lay out the different screens in your app and how the user might get between them. Using Storyboards was interesting, but frustrating at times. I think as a web developer, you subconsciously steer away from "visual" tools, maybe harking back to WYSIWYG editors of years gone by. You don't have to use Storyboards, they're completely optional. You can do everything programmatically. For example, in Permeate, you can click a link in a tweet and it will open that URL in an in-app browser (WebView). I chose to create this new WebView in the code and not in the Storyboard, as it was used temporarily and discarded fairly quickly by the user. Also, it's main content was the website the user was opening so it was less important for me to design any UI for it.

Overall, Xcode stood up strong and never crashed once. I still wouldn't use an IDE for web stuff, but for native, it was a delight.

Code

Wow wow wow Objective-C. You wrecked my tiny little JavaScript mind. I tried 4 times to learn Objective-C and only now am I able to code in it like a capable human. It's so different to anything I've ever used, but I kind of enjoyed (in a masochistic way) the challenge and brain-hurt of it's verbosity and strange ass-backwards syntax. But y'know, if you wanna make iPhone apps, please don't shortcut the learning and use RubyMotion or Phonegap, it's not worth it. Take some time to learn Objective-C. It'll pay off eventually. Until that moment, you can embarrass yourself on StackOverflow with me.

The one thing I would say, if you're struggling to grasp it, translate another app in another language into Objective-C and re-create something already done. I know we all learn differently, but personally, I find it so hard to relate to something new if I'm only looking at theory and abstract concepts and not putting something into practice as soon as I can. Using Permeate's web app algorithm as my base, I could just convert this line-by-line into Objective-C and really draw parallels between what I was most comfortable with and what I was learning.

As a quick comparison:

Objective-C

_tweets = [sortedArray subarrayWithRange:NSMakeRange(0, 10)];

Node.js

tweets = tweets.slice(0, 10);

So you can see, even though the Objective-C is a bit more verbose, it's pretty clear what it's doing when you have the JavaScript right next to it.

If anyone wants to see the full Objective-C translation of the above Node.js code, you can... here.

Plugins

Package management for the web is not solved. However, very recently I've started using Browserify for dependency management and npm as my package management. It's a dream. For native, save yourself the headache of manually downloading files from GitHub repos and use Cocoapods. Not really much else to say on that, but it worked really nicely and let me include a library into my application in ~30 seconds.

Design

A mistake I made with Permeate was not designing it in PS/Sketch first. Nothing really to do with the "designing in the browser" flame-war that happens every 3 months in the web community, I just found myself using Interface Builder (visual/behavioural manipulation in Xcode; fonts, colour, etc...) very clumsily and added unneeded friction to my design thinking and process. The next app I'll make, I'll design as much of the UI as I can in Sketch and then move onto code. For the same reason I like to design web UI elements in Photoshop/Sketch before I use CSS, is that when I design, I don't want to be thinking about CSS vendor prefixes or the box model, that crap clouds one's thinking. Same thing happened when I was trying to design Permeate at the same time as working out how to change a font size in Interface Builder. Not conducive to progress.

I found design, in general, a lot easier than designing for the web (not to say iOS design is easier). They're a few things that you can achieve in one line of CSS that take quite a bit of code to replicate with Objective-C. However, everyone knows that responsive web design is hard. Not having to deal with that on iOS was great. Assets become a lot easier to manage. Whereas on the web, people seem to want to tattoo #perfmatters across their belly, in iOS that kinda falls by the wayside. It's nice. Loading times are obviously still important for your app, but it's not so crucial as the web, where people scorn you for making a web page > 1MB or taking > 1 second to render your page. Apple encourage you to provide a launch image which is displayed to the user as your app loads up (this image is usually a screenshot of your app in it's initial, but blank state - a concept which the web community have only just started to employ). In future, I need to spend more time research iOS UI patterns as a lot of Permeate's design was driven by my familiarity of the web and it's design conventions.

Deployment

Holy hell Apple. Provisioning profiles. Code signing. Certificates. A really naive thing to say is that it was just way too complex, but as I'm naive, I'm gonna say it. It really could do with being a lot more seamless.

There was a lot of work to be doing with assets as well. Apple need screenshots and icons at different sizes and resolutions for different things. I guess if I was a bit more design savvy, then this might not have taken me so long, but oh boy, it did.

Updating

The long wait to update my app for people is gonna hurt...a lot. The App Store isn't Heroku (duh). What I mean is, the web is instant. One line deploys via the command line and every person from that point forward sees your brand new code. Entering a new world of OTA updates is going to be painful, but I guess that sending an update to someone's phone via the App Store feels a lot more personal. The updates become more meaningful and substantial.

Final notes

I started learning iOS properly in January on Treehouse and by reading various tutorials, but I took a long while to build up enough confidence to dive into Xcode and start building something. I was very aware that I'd make mistakes and knock my confidence before really even starting. However, once I did start, I'd say Permeate took me collectively around 24 hours. This was spread over a few evenings and weekends as I was still doing my usual freelance contracts in the day.

The app is totally free. Which goes against my ethos of product building, ie. I'd really prefer to work on chargeable products. But I figured, this is my first proper app, it was a learning experience, I don't have to provide any real support for it. So I didn't want the added pressure of making it "premium" enough for people to want to buy it. It has bugs, there are things I want to add or improve about Permeate, but I haven't got paying customers complaining to me about them. Just a few jokes asking for an Android version(?).

So I hope this mind-dump was in someway useful for people. However, if you just Pocket™ it and never read it, that's also ok, I understand.

If you do iOS and spot any errors in my process, or things that could be improved then please do holler at me on Twitter: @benhowdle.

I'll keep this post updated as other useful things come to mind...