Developing for iOS
Kartick Vaddadi (
[email protected])
What's mobile development like?
Constraints ● small screen (even iPad) ● user's attention span ● ● ● ● ● ●
CPU memory GPU storage network (flaky, slow and expensive) battery
Opportunities ● always with you, always on, always connected ● highly personal devices ● touch (direct manipulation) gives a sense of intimacy ● distraction-free devices ○ your app can really shine!
Opportunities ● Fun! People relate to their iPhone or iPad the way they don't to a PC (boring, impersonal device) ● what's your app's personality? ● app store opportunity (democratic)
Designing for mobile ● do few things, and do them well ● don't clutter your UI up ● ● ● ●
optimize for touch (44 x 44) [vs Android] responsiveness smooth animations design for single-handed use
iPhone iPad
Mac
iOS
(Mac) OS X
iOS (and Apple) Philosophy
iOS (and Apple) Philosophy ● Great, not good. Have high standards, and try to build something better than users even think is possible. ● Do it right or don't do it. Eg: copy-and-paste on iPhone ● Launch and iterate means: launch with a great user experience on day one, and add features over time.
iOS (and Apple) Philosophy ● Aim for an emotional connection. UIs shouldn't be merely usable; you don't go to a restaurant for merely edible food. ● Less is more. Build only the most commonly used features in your product. ● Build something great for 80% of your users, rather than something merely good for 100%.
iOS (and Apple) Philosophy ● Choice is only a means to an end, not an end to itself. Provide one great solution rather than two merely good options. ● Closed makes for a better user experience. Don't try to serve many masters. ● Technology should work the way people expect; not the other way around.
Philosophy w.r.t developers ● It doesn't automatically follow that what's good for developers is good for users.
● Apps needn't be allowed to do everything the OS can. ● Too much backward-compatibility is a straitjacket. Developers are expected to keep updating their apps as the OS evolves.
● Apple priorities: Apple first, users second, developers third.
Fragmentation vs Diversity two sides of the coin iOS is an easier target than Android to program for, in some ways.
● ● ● ● ● ●
screen size (but one size doesn't fit all) screen resolution (craft a pixel perfect UI) CPU GPU OS version ○ Android ICS: 5% after 5 months ○ iOS 5.1: 60% in 2 weeks App stores
SDKs
Cocoa Touch ● ● ● ●
Apple built-in to iOS similar to Cocoa on the Mac IDE with visual designer, debuggers, profilers
● Quiz: name an object-oriented superset of C
Cocoa Touch ● ● ● ●
Apple built-in to iOS similar to Cocoa on the Mac IDE with visual designer, debuggers, profilers
● Quiz: name an object-oriented superset of C ● Objective C
Alternatives: Web apps ● Not quite there yet ● Awkward ● no device or OS capabilities ○ address book ○ camera ○ notifications ○ background processing ○ integration with other apps ● no app store (discoverability, ratings, reviews, $)
Alternatives: Web apps ● Frameworks ○ iUI ○ Sencha Touch ○ SproutCore ○ jquery touch ○ PastryKit, TuneKit (Apple — unreleased) ● Almost there ○ ... for a few years now
Alternatives: Web apps
Don't.
Alternatives: Web apps Don't be lazy (minimizing programming effort at the expense of user experience). Your users demand a top-quality user experience, and if you don't provide it, they'll go elsewhere.
Speed of evolution iOS evolved far more than HTML5 in the last two years: Multitasking, iCloud, WiFi sync, AirPlay, AirPrint, Retina displays, notifications, push, Siri, iMessage, HDR photos, 1080p video, gyroscope, Bluetooth keyboards, inline autocorrect Committees are far slower.
Alternatives: hybrid apps ● Think native apps, but using HTML/JS rather than Obj C/Cocoa Touch ● Frameworks: Titanium, PhoneGap ● iOS and Android ● capabilities ● vision: best of both worlds ● Titanium also deploys as a web app. ● vision: best of all three worlds
Alternatives: hybrid apps Most hybrid apps are not good. Exceptions: Gmail for iOS Terminology for iOS (try it out! $1-2)
We'll focus on Cocoa Touch
API Design ● can't use private APIs (vs Android) ● hard boundary between API and implementation. API internals are not exposed for understanding, debugging or extensibility. Black boxes.
App Store ● ● ● ● ● ● ●
Apple knows developers' identities payment trail policy review (unlike Android) updates, too no remote code loading kill switch (== Android)
Sandboxing ● can't read or write outside your sandbox directory ● user can safely uninstall any app ○ ... as can Apple, remotely
● no browser plugins ● each app is fully self-contained ● no permissions manifest (unlike Android)
Security UI ● Security prompts for ○ location (both modal question and non-modal indication) ○ contacts (soon) & Twitter ○ notifications
● => limited user control (vs. none on Android) ○ too much control => disaster ● prompt on access (vs prompt on installation) ● up to 4 prompts (vs 1, for Android)
Multitasking ● background apps are frozen (vs Android) ○ can be killed at any time if foreground app needs ○ ○ ○
more memory save state when you go into background, in 5 sec OS hibernates your app if heap < 16MB limited background APIs
● memory warnings (no swap) ● OS manages background apps, not user.
Responsiveness When you go into background, freeze in 5 seconds, or you die. If you take too long to launch, or you freeze for too long, you're killed. (vs ANR on Android) Background apps can't: ● hurt the responsiveness of the foreground app (CPU, memory, I/O, network) ● kill battery ● run up a big data bill (but the built-in email app can!)
Cocoa Touch (Application Framework)
UI Frameworks
UI Frameworks ● UIKit: widget toolkit ● Core Animation: animation + rendering ● Quartz (or Core Graphics): drawing primitives ● ●
Core Text: text rendering OpenGL ES (for games and the like)
UIKit (widget toolkit) ● widgets like buttons, checkboxes, text fields, webview... ● layout ● painting ● event-handling ● delightfully easy animation
Quartz (drawing primitives) ● ● ● ● ● ● ● ●
lines, rectangles, Bezier curves, gradients transforms images and image masks transparency shadows color spaces hardware acceleration PDF and PostScript
Core Animation ● animation ● rendering pipline ● hardware accelerated ● blends content generated by multiple frameworks (UIKit, OpenGL)
Core Text (high-quality text rendering) ● ● ● ● ● ●
Text rendering Text layout Line-breaking Kerning Ligatures Justification
(You probably won't need Core Text.)
UIKit Layout ● Virtual co-ordinates ○ floating point (vs Android) ○ Android has multiple units ○ Retina displays - 2x
● Can design your UI for specific resolutions ○ 320 x 480 ○ 1024 x 768 ○ vs Android
● No support for padding!
Autoresize masks ● Declarative
● Control size and position ● Constrain: ○ width ○ left ○ right ● Similarly for the y dimension ● Can do it programmatically (layoutSubviews)
Layout Details HTML is bottom-up (as a first approximation):
Parent is sized based on children.
Layout Details UIKit layout is top-down Parents are laid out first, and their size is used to layout children Android supports both: ● a child can be small enough to fit its content ● or large enough to use up all free space in the parent
Dynamic Layout
● How big is the article itself (parent)? ● depends on children! ● Dynamic layout support is broken
Dynamic Layout ● easy to trigger infinite layout cycles ○ asynchronous!
● or kill scrolling performance ● took me a month to get right ○ you're fighting the system
UIKit Rendering ● views are snapshotted when first displayed ● the backing store is then rendered by the GPU ● example: scrolling ● extremely CPU-efficient ● the backing store is reused until the state of the view changes
UIKit Rendering
Parent View
Title View
Body View
Photo View
Parent Buffer GPU
Title Buffer
Body Buffer
Photo Buffer GPU GPU GPU
Screen
UIKit Rendering ● backing stores use tons of memory. OOM. ● can be more than everything else in your app! ● can't turn them off for specific views ● Android lets you turn them off, or use a vector representation.
Animation Without animation: imageView.alpha = 0; With animation: [imageView animateWithDuration:0.4 animations:^ { imageView.alpha = 0; imageView.x = 1024; }];
Threading ● UI thread ● Never block the UI thread (for the network) ○ ... and, on Android, the disk
● Asynchonous network API ● runLater ● runWhenIdle ● The power of threads without the pain ● But need threads to take advantage of multiple cores
Grand Central Dispatch ● Task queue on steroids ● "Execute this function on another thread and give me the result" ● Extremely low overhead (256 bytes) ● Scalable ● No thrashing ● Dependencies
iCloud ● ≠ Dropbox, Google Drive, etc ○ back up/sync a folder
● iCloud backs up the entire state of the device ○ ○ ○ ○ ○
apps your data in apps app settings OS settings (wallpaper, email accounts, photos) everything!
iCloud ● Free quota for each user (5GB) ● ... and for each app Two stores: ● key-value pair (for app settings) ● directory (for app data) ● automatic sync ● notifications when there's a change
Mmm, that's a beautiful walled garden you have there!
iCloud Only on: ● iOS ● OS X, but only Mac App Store apps ● Windows, but only partially Can't write your own web apps (no network API)
Tools
Core Animation Instrument
One more thing...
Priorities ● It's not just the tools, but also the culture and the priorities. ● Are you willing to spend half a week optimizing the scrolling to be smooth?
References (UX) "Tapworthy" book. If you read only one thing, read this. goo.gl/Uot66 Apple Human Interface Guidelines: goo.gl/REwiE "Designed for Use" book, and especially articles, at designedforuse.net
References (UI Frameworks) Core Animation: goo.gl/4M0r4 Dynamic Layout in UIKit: goo.gl/lFx50 Understanding and contrasting the iOS and Android rendering models: goo.gl/h2Y8s
References en.wikipedia.org/wiki/Cocoa_Touch Grand Central Dispatch: goo.gl/9Akwm OpenCL: goo.gl/iayBl
References en.wikipedia.org/wiki/Objective_c Automatic reference counting vs GC: goo.gl/vHOFw Clang: goo.gl/raIWd iOS dev center: developer.apple.com/devcenter/ios/index. action
Questions?
Backup slides
Objective C
Objective C ● Object-oriented ● Far simpler than C++ ● Almost as productive as Java ● Not as performant as C++ ○ but can always drop to C (superset) [vs Android]
● No VM (unlike Java/Android)
Interesting aspects of Objective C ● Both higher and lower level than Java ● ● ● ●
Both static and dynamic typing Properties Method forwarding Categories: add methods to existing classes (even system ones) ● Non-fragile instance variables ● Zero-cost exceptions ● Toll-free bridging
But I like C++! ● Can reuse C++ libraries ● Instantiate C++ classes from Objective C and vice-versa ● Catch C++ exceptions ● Objective C++ == Objective C ∪ C++ ● iOS APIs are in Objective C and C ● Implementation is in Objective C, C and C++
Memory management ● ● ● ● ●
Closer to Java than to C++ Automatic ... in most cases Reference-counted need to handle cycles ○ by marking weak references
●
Full GC is not available ○ responsiveness ○ you have only 16ms
Alternatives: almost-native apps ● RubyMotion ○ ○ ○ ○
code in Ruby invoke iOS APIs compile to native code (no interpreter) profit!
OpenCL ● The GPU is more powerful, but idle ● C-like language that can run on the GPU... ● ... or on the CPU ○ fallback ○ some things are faster on CPU
● Available on Mac OS X ● Not yet available on iOS ○ ... for apps.
Tools ● Objective C ● OCUnit ● OCMock
XCode ● If you like it, you'll really like it. Or you'll hate it. ○ Like Apple itself
● No plugins (Perforce) ● Not bloated like Eclipse with 10,000 options. ● Visual design tool ○ binary blob (vs XML for Android)
● graphical debugger
Compiler: clang
Tools ● Activity Monitor ○ Similar to (non developer-facing) Activity Monitor on ○ ○
Mac OS X Overall device and per app CPU, Physical and Virtual Memory, Network, I/O
● Allocations ○ heap size in MB and number of objects ○ by type (C, Obj C, Core Animation backing stores) ○ churn
Tools ● Leaks ○ ○ ○ ○ ○
address size responsible function number of instances bytes used per class
Time Profiler
Tools I wish iOS had ● Hierarchy viewer ○ shows you the size and position of each view ○ invaluable when the UI doesn't look or work the way you intend
● Monkey ○ randomly keeps tapping and swiping at your UI to try to provoke a crash ○ saves the event stream so you can repro
Simulator ● superfast ● is merely a Mac app that implements iOS APIs on top of Mac OS X ones ○ APIs are pretty close
● Android emulator emulates a whole CPU and runs Android OS on top of it.
Security ● W^X ○ => no JIT ○ Ruled out by policy, anyway
● ASLR (Address Space Layout Randomization) ● single-process (no Chrome) [unlike Android]
Energy Usage Instrument
Energy Usage Instrument
Network Profiler