Onboarding: Facebook vs Twitter

The on-boarding process consists of gathering a user’s email address and password among any other information necessary for the app such as user avatar, full name, gender, or bio. In the days prior to social login, this was always done with a long and boring registration form. Over the years the on-boarding experience has gotten far easier with social logins such as Facebook, Twitter, and LinkedIn.

Some apps give you the option to login with either your Facebook or Twitter account. My experience has shown that it’s best to limit login to Facebook. The problem with Twitter login is that the user’s email is not provided by default, thus an extra prompt is required to acquire the user’s email – which is a bit clunky and can turn users off. Thus, I try to limit login to Facebook only. The true on-boarding process should be a mere press of a button and nothing more than that. Further, it’s safe to say that all Twitter users are Facebook users, but not vice versa.

Google Maps vs Apple MapKit, which is better?

The two most popular map frameworks available for iOS developers are Google Maps SDK and Apple MapKit. Now there’s also MapBox and a few others, though I won’t address those today because they are NOT free to use and they are less common.

Before jumping into a simple comparison of the two frameworks, I will say this: Google is an information based company whereas Apple is a electronic product and services based company. Google doesn’t want your money – they want your soul. Google will give you everything you want for free if you just use Google. Apple will make you pay for everything – and a lot for it.

It’s important to understand that Apple doesn’t generate revenue from MapKit, where as Google Maps is a part of its core ad revenue. Thus, a reasonable expectation is that Google Maps SDK would be better – simply because there’s motivation for it to be.

In my experience, this turns out to be true. Let’s take a simple example. Suppose you’re building an app that allows users to tap on different neighborhoods in their city. Each neighborhood is essentially a polygon. Both frameworks allow you to draw polygons to your heart’s content. But what about detecting a tap on a polygon?

Google provides this delegate callback:
- (void) mapView: (GMSMapView *) mapView  didTapOverlay: (GMSOverlay *) overlay

What does Apple provide? Nothing! Absolutely nothing! I was just shocked and clenching my fists.

OK, so what else does Google have to offer that trumps over Apple in the domain for mapping?
Take a look at this simple API:
http://maps.googleapis.com/maps/api/geocode/json?address=325%20West%2093rd%20Street%20#1D

Walla, so much information in a mili second about any address in the world!

Streaming YouTube videos

Suppose you want to build a YouTube app – or just a video streaming app that sources YouTube video. YouTube provides a library known as YTPlayerView which allows you to stream any video from YouTube. Sounds great! But wait until you try it:

* Annoying YouTube advertisements everywhere

* Only one YTPlayerView can be used in your app at a time

* When the user pauses the video – it stops streaming!

Clearly, YouTube doesn’t make it very easy for developers to really build great YouTube apps with the full freedom to allow fresh creativity. Wouldn’t it be great if there was a YouTube API that accepted the Video ID and returned all the download links? Luckily, there is!!! Check out these two great API’s:

YouTube Grabber

SaveDeo

YouTube Grabber is completely free, and SaveDeo is free to try with the first 200/daily API calls free of charge. SaveDeo returns a very rich json, full of download links to various formats of the video and the thumbnails as well. I highly recommend!

Multiple AVPlayers

I recently built a video creation and sharing app, something like Instagram for video. This app has a feed of videos, up to one hundred AVPlayer’s in a single paged UIScrollView. A feed is a collection of AVPlayer’s in a single paged UIScrollView, where feeds can be stacked on top of one another using a UINavigationController. With only five or six videos loaded in each AVPlayer – there are no issues at all. However, when 10 or more AVPlayer’s have been allocated and are active across various feeds, performance starts to deteriorate quickly. Memory warnings pop up everywhere.

My first attempt was to ensure that only three AVPlayer’s would be allocated at any one time. Even this proved to be insufficient with various hiccups in performance. Finally, I realized that only one AVPlayer should be allocated at anyone time for optimal performance. Thus I created a singleton class especially for this AVPlayer.

The second issue to address is download of the videos and a clever and intuitive way to indicate to the user the download progress. I opted for a UIBlurEffect on top of the video still image. As the download progresses, the alpha attribute of the UIBlurEffect is reduced to 0. When download is complete, the AVPlayer is allocated and the video is loaded into the AVPlayer.

Lastly is the issue of downloading the videos themselves. With a WiFi connection, it is possible to download as many as 20 videos as once, but with an LTE connection – it is best to download one video at a time. I catered for the lowest common denominator and reasoned that only one video should be downloaded at a time – to be stored in the app’s documents folder. Download of video is initiated upon swipe to a new feed item.

To autolayout or NOT to autolayout? That is the question …

Autolayout is a cool feature Apple introduced several years ago which transforms the way in which developers think about laying out their views. In short, autolayout is incredibly easy to set up and use with Interface Builder – but quite a pain in the neck when doing so in Objective-C code.

For those of us code purists that refuse to use Interface Builder – the question remains – to use autolayout or NOT to use autolayout? Should we just continue to set the frame of each view and simply set the autoresizing mask when the view needs to be adjusted dynamically? After all, adding and removing constraints is a real pain, so why not just set the frame and have a nice day?

My answer is the following: always do what is simplest and works best – the path of least resistance is the golden path. In some cases, the extra overhead of laying out views with autolayout in code is actually worth it! This applies for universal apps with a responsive design that must adjust to screen rotation (portrait and landscape mode). But for those apps that only support one screen orientation on a single device type, it may be simpler to set the frame in code.

NIB Files and Storyboards vs. Pure Code: What it means for iOS 8

The debate between using NIB Files vs laying out screens in pure code has been raging on since the birth of Apple’s Interface Builder. In one camp are the visual developers that love being able to see their screen in Interface Builder and laying all views out visually. In the other camp are code purist developers that worship code and detest any tools that do “magic and wonders” behind the scenes but with little to no understanding of the magic. The battle is symbolic of the ongoing rivalry between the two biggest mobile companies in Silicon Valley: Google and Apple. Google has banned the use of NIB/XIB files several years ago in their iOS projects – while Apple has made it clear that NIB’s are the preferred way to go.

I am NOT here to fight for either camp. I will only say that developers should be able to work in whichever way they prefer – what is good for me may NOT be the best for another developer. So long as everyone is happy – I don’t care what is your sexual orientation, ethnicity, nationality, religion … or your coding habits (that is so long as you deliver quality work).

That being said, with the release of iOS 8 and the larger screen sizes introduced with the iPhone 6 and iPhone 6 Plus, developers in the pure code camp may be in for some trouble! Several years ago Apple has introduced a new technology and screen layout methodology known as Autolayout. What exactly is Autolayout? From Apple: “Auto Layout is a system that lets you lay out your app’s user interface by creating a mathematical description of the relationships between the elements. You define these relationships in terms of constraints either on individual elements, or between sets of elements. Using Auto Layout, you can create a dynamic and versatile interface that responds appropriately to changes in screen size, device orientation, and localization.”

For anyone that has tried massing around with Autolayout using Interface Builder – you’ll soon realize that it doesn’t take long to learn the ropes and get moving quickly with it. For anyone that has tried getting Autolayout to work in code – good luck! It’s a real pain in the butt. A single view rendered in code using Autolayout requires some 20 lines of code – and NOT only in Objective-c – but in a whole new language called Visual Format Language (VFL). As if learning Objective-c wasn’t hard enough to learn …

The alternative to Autolayout (and its predecessor) is simply setting the frame of the view in code using an old and favorite function known as CGRectMake. If the view has to be dynamically resized for any reason – no problem! All one has to do is set the automask property of its subviews to resize along with their superview.

The issue with this old and trusted approach is that the new phones released last month have a larger point resolution than the 320 point width of the older iPhone 3/4/5. You may ask yourself, why didn’t Apple simply make the iPhone 6 and iPhone 6+ have a 320 point width so that existing apps wouldn’t have to be re-written? There are many answers to this – but my guess is that Apple expects everyone to migrate to Autolayout along with Interface Builder – and if you don’t … well, you’re on your own.

Initially, I decided to throw in the towel and become another lamb in the Apple clan – but then I remembered why I became an iOS freelance app developer in the first place – I have a brain and I like to use it for myself! I stared thinking about how I can continue to set view frames in code without reverting to Interface Builder or spending 100’s of hours writing Autolayout in code. I soon came up with two solutions to this problem – and both are working like charms for me. If anyone is interested to learn more – simply contact me and I’ll share the two solutions (it’s simpler than you may think).

How to make wireframes for iPhone with rapid prototyping

There are plenty of wire-framing software out there. Among them is the well known Prototypr, FluidUI, UX Pin, Balsamiq, Moqups, Proto.io, Mocking Bot, Mocking bird, Pidoco, Appery, Realizer, Mock Flow, Hot Glue, Mokk.me, and the famous and industry loved Invision. And for the real pros: Photoshop. But there is an easier way to get started: Enter Google Drive Drawing! Below is a link to a complete wireframe for a simple five screen iPhone app that I was able to make for a prospective client in the span of only 30 minutes:

Example Wireframe Set

Screen Shot 2014-10-11 at 3.05.13 PM

Screen Shot 2014-10-11 at 3.22.09 PM

The beauty of Google Drive Drawing is that you can remotely share it with your client and update it in real time for them to see.

As can be in seen in the wireframe set – it is incredibly easy and fast to make these wireframes! Start out by asking your client: “What is the first thing the user will see when they enter this app”? Then simply place down on the screen whatever UI elements the client tells you. As you start drawing buttons and inserting images – the client is impressed and at the same time excited by your ability to quickly and seamlessly take an abstract idea for an app and put it on paper.

It is important to pick the client’s brain about every UI element that you end up drawing. You’ll be asking questions such as:

1. Which screen will this button take the user to?

2. Does this screen need a back button?

3. What happens when the user presses the pin on the map?

4. What will the be the popup message if the bar code scanning fails?

The answers to all these questions must be written clearly and expounded further in the form of annotations  which appear below each wire-screen.

Imagine being able to scope out every small detail of an app within the span of an hour? You and your client are on the same page – the expectations of the project are NOT only evident – but clearly visible – and if there are any design mistakes or loopholes – those can be easily traced and addressed as well. As a designer or developer you now have a solid foundation for giving the client a solid quote for the next phase of the project.