The Separation at Birth — Mapping Web to iOS Development
Brothers don’t shake hands, brothers gotta hug. Web and iOS development are no different in this case. They can both act as clients that make API requests. They both act as UIs to display information to a user. Let me create the mental map for your web developer mind to translate to iOS.
Elements
When you first learn about web development, the most basic thing you can learn about are the HTML elements. In iOS they are really just another high level library that Apple created called UIKit, and thusly name UIKit Components. These HTML elements and UIKit Components don’t completely match 1:1, but the way in which you mix and match the elements or components will allow you to achieve the same look and feel. This is not a complete list, but are the most common elements that I used while learning iOS.
UILabel: This component is used for any text that is to be displayed in app. So in terms of HTML elements this replaces <p>, <span>, <label>.
UIView: Use this to act as any generic component in app. All components extend from this parent class. I like using this to group many small components together to act like a <div>. To create custom Components most people will extend from UIView.
UIImageView: Like the name suggests, this is used for images. HTML elements that it replaces: <img>.
UIButton: The name says it all with this component. This element is used for the most basic of user touch interactions with the app. And like with any HTML button, UIButton can setup listeners to trigger code on user events such as
- “touch up inside” → “click”
- “touch down” → “mousedown”
- “touch drag enter” → “drag”
list of events: http://stackoverflow.com/questions/11389915/uibutton-events-whats-the-difference
UITextField: Use this component to input text, which would replace :
<input type=”text” />Not too much magic that happens here, but you can also attach events to UITextField such as
- “touch up inside” → “focus”
- “editing did changed” → “change”
- “editing did end” → “blur”
UITextView: Use this component when dealing with long blocks of text such as an email message or a long description. This is most similar to <textarea>, and has the same events as the UITextField.
UIScrollView: ScrollView is like a scrollable <div>. If you have too much content in app, it will all be hidden since you don’t get scrolling for free like the browser. To fix this you will need to place it in a scrollview. The most common configuration with scrollView is to enable paging mode. This is where each app screen looks and acts like a page. Many iOS developers use this to enable draggable side-menus.
Really good guide: http://guides.codepath.com/ios/Scroll-View-Guide
UITableView: Probably one of the most commonly used components in iOS. You can see examples of this being used in Twitter, Yelp, Rotten Tomatoes, the Mail App, the Phone Book App, the App Store, the Notes App, and pretty much any app under the sun. This is used in conjunction with UITableViewCell, which is the subview that lives within the tableView.
There is nothing in HTML land that compares to a UITableView, but think of it as a way to create a list of one or more of the same subview (cell). Here at points in our webapp we have examples of a list that correspond to tableViews, such as the exchange program modal and add program sidebar.
Building UI
Now putting all these piece together is the real work. In web development we use html, css, and javascript. There is a clear division of responsibilities, where HTML has all your structure and markup that your page contains, CSS contains all your styles, color, and beauty, and javascript contains the logic and “UI Magic” that we see on the page. These files are just simple text files — Easy to read and understand if you’re familiar with code. I may be biased, but this approach is far more straightforward, but possibly more error prone than developing with iOS.
storyboards
iOS is a whole other beast. The most universally accepted method is the use of storyboards. They show the developer or designer high level view of a portion or the entire application. Its very clear and simple to look at each screen at every point in the app flow. You can easily add UIKit Components into the storyboard, and get a preview of what your app looks like without having to build/run it.
Of course there are drawbacks. Storyboards don’t work well with large teams. Code conflicts are very much a part of a developer’s life, and these visual conflicts are not something you want to deal with on a daily basis. This method also requires a larger understanding and comfort with Xcode as man of the components can be styled just using the interface builder (storyboards and Xcode).
xibs
Are much like storyboards in that they visually layout a view’s elements. What they don’t have is a high level application flow, since its just one element in the app. I used this most when creating UITableViewCells, but was then corrected to just use storyboards for the same thing. So when in doubt just use storyboards.
code
The tried and true way for most large dev teams are just coding these babies up. Using a combination of storyboard-like text files and Objective-C/Swift ViewController files, you can programmatically build up an app’s UI. This of course is the most verbose way of doing this, but also allows for maximum flexibility and customization. The other great benefit of doing it this way is decreasing code conflicts. There is also a lot less hunting through Xcode interface builder for styles and enabling/disabling features/properties of elements.
In the end a dev team will probably need to use a combination of the three to achieve a complete app. There is no one solution to this, and really will depend on how everyone works together.
I hope this binds the glue in your mental map of understanding iOS a little bit better. This again is just a high level explanation of a few of the basics, so please look out for more posts in the near future!
