Designer Learning iOS Development

[iosdevbydesign]

Controlling UIViewController complexity in Swift with Pokemon

Summary

I find a really common desire in the indie iOS development community is to stop UIViewController subclasses from becoming gigantic. I can definitely see why: UIViewController does a lot and becomes the dumping ground for lots of capabilities. With that in mind, I tried to think critically about what should go into a view controller and what should not go into a view controller.

If we think about MVC, then the view controller should really only be doing three things:

Displaying Data from the Model

Handling Input from the View

Performing CRUD operations on the Model based on the input

That means, as long as we keep the interaction with the views and the models to 1 or 2 liners in the view controller, we’ll have a nice, compact, view controller.

However, Apple threw a big wrench into the works. It is also the responsibility of view controllers to present and dismiss other view controllers.

I think this is where the complexity tends to multiply

The Problem of the Initial View Controller in Storyboards

I find that Storyboards encourage you to work with view controllers in a certain way. The storyboard wants you to have an “Initial View Controller.” This view controller tends to be gigantic because its the main display of your app.

It tends to know about all the other view controllers that your user can browse to while using your app so that it can present them.

It knows about your model because thats usually the main scree of your app.

The storyboard also encourages lots of ancillary view controllers that do things like Adding things / editing things / settings / etc.

I find these controllers are generally pretty light.

Segues can reduce the load on the Initial View Controller, because the Segues handle presenting view controllers by themselves.

However, usually the Initial View Controller needs to configure segues before they can occur.

Existing Suggestions

Helper Classes: This is a big one. I use this a lot, even in the solution we’re going to be talking about. Helper classes can sit in-between the model and controller or the view and the controller and help format things. This makes it easier to keep code in the view controller down to 1 liners.

Functional Reactive Programming / MVVM: FRP is a big one and I really want to learn FRP. However, its a big change over how Apple does things and the way I’ve learned. It also requires big Swift frameworks that make keeping up to date with Swift versions really hard.

Flow Controller: The flow controller is essentially an object that lives “above” any view controller. The flow controllers job is to keep track of which view controller is on screen and help switch from one to another.

My Suggestion - Control Complexity with Multiple Subclasses

We’ve all created subclasses before. We do it every time we make a custom view controller. I find that subclassing not once but 2, 3 or even 4 times can really help separate concerns, control mutable state, and keep your code files really small.

As you add new capabilities to your view controller, you just add a new subclass somewhere in the inheritance tree.

Properties and methods can be marked as private. This helps control mutable state and side effects between subclasses.

Any critical events that multiple subclasses need to know about can be done with methods that the subclass overrides: e.g. a “dataUpdated()” method for when the data source changes.

You can spend as much time as you like making the higher up subclasses more re-usable: e.g. a subclass that displays data in a table view does not need to know about custom data types. They could be represented with a simple protocol.

Swift is here to help!

Immutability: Swift has immutability. You can mark data and helper classes and other objects that the view controller needs as constants and then subclasses cannot change them.

Access Control: Swift has access control. Any subclass can mark methods and properties as private and then no other subclasses or superclasses even know they exist.

Explicit Overrides: Swift requires that overridden methods and properties be declared as such. This makes refactoring mistakes almost impossible: the compiler won’t let you continue until you fix the problems in the subclass.

Catch all the Complexity with Pokemon!

We’re going to create a Pokemon app. This app is going to have capabilities that most apps have. Its going to download a list asynchronously. Its going to allow viewing more detail of a Pokemon. Its going to allow creating and deleting Pokemon. Our initial view controller already has 3 responsibilities.

Async CRUD capabilities for the data (and showing loading states)

Showing Data in a TableView

Presenting new view controllers for adding and viewing Pokemon.

Data Source

First we need a basic data source. This one is going to use a Pokemon API I found online. This data source has a private method that downloads all the Pokemon and calls a completion handler when finished.

It has all 4 CRUD methods, but I didn’t implement the update() one.

The read() method just calls the private method that downloads all the Pokemon.

Where do we place this class? A singleton? On the view controller? I don’t like either of those solutions.

I just add it as a property on the App Delegate.

This allows the data source to be reset in emergencies (unlike a singleton)

This also removes it from the lifecycle of the view controller.

Bottom View Controller and Storyboard

We need a Bottom View Controller file. This view controller file will have no code. It will always inherit from the one of the subclasses of our Pokemon View Controller. The basic point of this VC is so that we never have to change our Storyboard. We can continually insert subclasses into the middle and never have to change the class registered in the storyboard.

Set up a table view in the view controller. Also add a UIActivityIndicatorView that the view controller can start and stop the the Pokemon are downloading.

First 2 Subclasses

Now we need a CRUDViewController and a TableViewController. Note, not UIKit’s UITableViewController. I named mine JSBTableViewController so we don’t mix them up.

Connect the IBOutlet for the UITableView in the storyboard to your table view controller. Then connect the IBOutlet for the UIActivityIndicatorView to the CRUDViewController. Yes, you can do this. Interface builder is awesome! :)

The TableViewController is going to do the work of displaying Pokemon in the tableview. The CRUDViewController is going to read the data from the data source. Look at the screenshot below to see how the concerns are separated.

Notice how the TableViewController does not know where the data came from or how it got there. It just knows its data changed and then updates the UI accordingly.

Also notice how we created a copy of the data for the view controller. Since Swift Arrays are Structs and the Pokemon type we defined is a Struct, we are getting a completely unique copy of the data for the view controller. That way, the data source can keep doing whatever it wants and it won’t interfere with the view controller.

Keep in mind that CRUD operations on the Data Source may need to be more sophisticated because when doing this data copy because the view controller data and the data source data can get out of sync.

CRUD Protocols

I’m not going to implement Update in this sample code, but Create and Delete are easy. In the CRUDViewController file we can define two protocols, AddPokemonDelegate and DeletePokemonDelegate. The CRUDViewController will conform to these protocols.

Then any Add / Delete / Update view controllers will get a reference to the CRUDViewController. This reduces tight coupling between the ancillary view controllers and your data source. It also makes it so the only object changing the data is the view controller displaying the data. This avoids having to deal with being notified when the data changes.

Segue Handling View Controller

We need a view controller that knows how to prepare the ancillary view controllers to be presented. Storyboards give us an easy way to do this, -prepareForSegue:sender:. However, add this to either the CRUDViewController or the TableViewController doesn’t make sense. This has nothing to do with either. So lets make a SegueViewController that inherits from CRUDViewController

This SegueViewController has one job: It knows what the possible segues are and its tightly coupled with other types of view controllers. It knows how to populate the needed data from the data source to new view controllers.

Add and Detail View Controllers

Now in the storyboard we can create an Add Pokemon Scene and a Pokemon Details Scene and create the associated segues needed segues.

Each of these view controllers needs very little code. They each need their associated IBOutlets. Then they need a weak delegate property. The delegate property should be one of the CRUD Protocol types.

Add Swipe to Delete

Since we already did all the work to make deleting Pokemon possible, lets enable swipe to delete.

The question is where should we implement -tableView:commitEditingStyle:forRowAtIndexPath:? Well, its up to you. The TableViewController knows about tableviews. But the CRUDViewController knows how to delete things.

I would implementing it in CRUDViewController because it knows how to delete things.

Finished App

Next Steps

Whats next? Think of something else a view controller should do and implement that as a new subclass.

First run experience:

Don’t implement all of the first run experience in a new file.

Instead, use the new file/subclass to present the view controllers related to the first run experience.

State restoration:

If you wanted your view controller to participate in state restoration, you could add a new subclass (near the bottom) that knows about all of its super classes state and saves and restores it.

You could also implement this on each subclass so each one is only responsible for its own state.

Either way, its way better than bloating an already bloated view controller with tedious state restoration code like we would have to do if the view controller was in one giant class.

Conclusion

Ok!, we’ve learned to embrace the fact that Apple has seen fit for view controllers to do a bit too much in the iOS world. Yet, we’ve managed to separate concerns, keep our code clean, and control state.

Remember, don’t go crazy with this. This is just another tool in the tool belt. If you find a single view controller is getting more than 5 or 10 subclasses deep, you probably need to rethink your architecture.

Pokemon Sample Code Repo on Github

Feedback

Thanks for taking the time to read this really long post. I hope you enjoyed it.

I love hearing feedback. Especially if you dislike the idea and why. I just ask that you be civil.

I can most easily be reached on Twitter:

http://www.twitter.com/jeffburg

[iosdevbydesign]

In-App Purchases in Swift: Part 4

Summary

This is the fourth of many posts on handling In-App Purchases in Swift on iOS. The first post was a high level overview of how to read and verify the built in receipt. The second post was a review of the View Controller design and implementation for In-App Purchase. The third post was code review of my CompletionHandler based purchase manager class. This post is on handling errors and showing them to the user. Error handling is quite complicated for IAP, I’m pretty proud of thoroughness of my error handling solution in Gratuity..

Errors on iOS Suck

Sucks? Compared to what? If any of you are ever adventurous enough to play around in AppKit/Mac OS X programming, you’ll see how terrible iOS errors are. In OS X, the NSError instances you receive back from Apple’s API’s are amazing. They have a localized description and a localized recovery suggestion that you can show to the user. They come with a severity level. Also, the NSAlert API from Apple allows you to initialize an alert with an NSError and show it right to the user (shown above) with no manual configuration on the developer’s part. Its fantastic

On iOS, the NSErrors you receive from Apple API’s are gibberish. They have descriptions that are barely understandable, even to developers. The have no recovery suggestions. Because of this, they really can’t be shown to the user without manual manipulation. Also, UIAlertController cannot take an NSError and show it to the user. The developer has to manually configure the text in the UIAlertController.

On top of that, the StoreKit Framework has not been updated very well for Swift. So the error values that come back are not convertible to an ENUM. So I had to manually create an ENUM so I could process all of Apple’s StoreKit errors. (Shown below)

All Possible Errors ENUM

In order to start Error handling, I first had to enumerate all the possible errors. This required planning ahead. But I also wanted to make it so that if a new error needed to be added later, it would not be difficult.

I made an ENUM that represents all possible errors for all of Apple’s errors plus other errors that may arise. Notice that there are separate errors for Restore and Purchase processes. This probably isn’t strictly necessary, but I wanted to be able to have different text for Restore and Purchase errors.

Also, take notice of “RestoreSucceededSplitBillNotPurchased.” Thats not an error according to Apple. When the user restores purchases, it doesn’t mean they’ve actually purchased the item. It only means that they successfully told the App Store to restore them if they existed. So you need a different error for the case of “Hey, this App Store Restore succeeded, but you’ve never bought this, please purchase it.

Lastly, notice that the errors all have an Integer rawValue. I don’t normally do this in Swift, but when dealing with NSError you need an error code that is in an integer. You can then initialize the ENUM with that rawValue.

Error Localizations

Once you’ve considered all the possible errors, and thought of the localized strings needed for them, you’re ready to begin. A lot of people have said that Swift has much better ways of dealing with errors than NSError (namely Swift ENUM’s with associated objects) but because StoreKit is going to be giving me NSErrors, I would just stick with NSError. Its quite easy to deal with them because of convenience initializers. I made a convenience initializer for NSError that takes my ENUM and switches on the ENUM to populate the NSError UserInfo dictionary with the appropriate description and recovery suggestion.

Don’t be afraid of the strange way I do the localized strings. I decided to make a lot of Structs with constants to define the localized strings. The advantage of this is that you can take advantage of namespacing in Swift to keep localized strings contained within the relevant ViewController or other class. Also, you can put all the localized strings in one file. That makes it easier to generate the Strings file later.

Reducing UIAlertController Boilerplate

Since I knew I would have a lot of errors, but they would mostly follow a similar pattern, I created convenience initializers for UIAlertController and UIAlertAction. The controller takes care of the style of the alert: i.e. is it an alert in the middle of the screen or the bottom of the screen. It also shows the localized description and recovery suggestion. Lastly, it takes an Array of UIAlertActions. Those are the buttons at the bottom of the alert that can do something when the user taps them.

The convenience initializer on UIAlertAction allows me to specify 1 of 3 types that I need and give it a completion handler which is a function Void -> Void and it gives me the correct localized text for the button.

The convenience initializer for UIAlertController takes an NSError (remember the OS X example I gave earlier. I was inspired by that) and an array of UIAlertActions and creates an alert controller with those actions and with the localized description and recovery suggestion as part of the alert controller.

Finding the Appropriate Error

Back in the Purchase View Controller, we need to take the errors that come back from Store Kit and replace them with our custom errors. I’ll be the first to admit, I’m kind of embarrassed by this code because its a giant method that goes through way to much logic to keep track of. Its ripe for refactoring to make it shorter and easier to understand. I’m just showing a small portion of it here. But basically the way it works is that it takes the SKTransaction I got from the StoreKit purchase manager class I made. It goes through the original error, converts it into a “User Facing Error” and returns an array of UserAlertActions that are appropriate for the User Facing Error.

Some details to notice. I set the userFacingError constant to .None (nil) when an error should not be presented to the user. This happens for a couple of StoreKit errors. Namely. when the user cancels the purchase. I also populate the array of actions with the appropriate actions. The appropriate actions are usually just Dismiss and Email. But sometimes there is a Buy action as well. At the end of the method (not shown), I return the userFacingError and the Array of Actions.

UIAlertAction is really convenient because its completion handler based. That means you can leave the code for when the button is tapped near the spot where the button was created. However, in this case that would be bad because I have a bunch of email buttons created in a bunch of different places. So, instead of giving the email support action a bunch of different completion handlers copied and paste over and over, I made a single function on the view controller that I pass in as the completion handler. Its so nice in Swift to be able to do this. You can pass in any variable or method that has a matching function signature (Void -> Void in this case) and that closure/block/function will be called when the completion handler is called.

Presenting the Error to the User

In the IBAction for the “Buy” button there is a completion handler for buying the IAP. In that completion handler, we need to check for errors and display them to the user. If there is no error, then the purchase worked. Or if there is no error and the purchase did not work, the user tapped cancel and we do nothing. Notice, how the code is relatively short because of the convenience initializer on UIAlertController, NSError, and because the UIAlertActions were decided in the errorForPurchaseTransaction() method shown before.

There is one tricky part of this code. Notice, I check if the View Controller still has a presenting view controller before trying to show the UIAlertViewController. I do this because the completion handler causes the view controller to be retained and in memory even if its no longer in the view hierarchy and trying to present a view controller from a view controller not in the view hierarchy causes an error (not a crash) so I just wanted to avoid it. This happens when the user opens the view controller and starts the purchase and then closes the VC immediately. When the purchase finishes, that code gets called even if the view controller is not in the view hierarchy. I should note that this is what I want.

I could use [weak self] in the closure so the view controller is released along with the purchase manager when the user dismisses it even if its in the middle of a purchase. However SKPaymentQueue holds an unsafe unretained pointer to all the objects observing the queue. This causes a crash if the view controller (and its purchase manager) get released from memory when the user dismisses them. Very bad.

Email Support in Error

I thought it would be nice to allow the user to email directly from an error prompt. My thinking behind this was that a user may be upset and if I don’t give them an easy way to email, they might leave a bad review in the App Store instead. It turned out to be a little difficult to add the email option because there is some logic that goes into opening an email prompt and I didn’t want to have to copy and paste that logic all over into a bunch of completion handlers for the UIAlertAction. I covered how I solved that earlier in this post.

The other thing I needed to solve is sometimes I wanted the View Controller to be dismissed after the user was done with the email and sometimes I didn’t want it to dismiss. For example: If I can’t download the price of the item, there is no way to continue from that point with any purchases, so the view controller should just close after the email is sent.

The above screenshot shows how I handled the logic for opening the mail compose view controller and how I handle finishing sending the email. Basically, I have a boolean property on the view controller that gets modified by the StoreKit completion handlers before the user can open the mail compose view controller. When the user is done sending the email, the delegate callback checks that property and acts accordingly.

Summary

I started this post thinking it would be one of the shortest, instead it was one of the longest. I think this goes to show just how complicated Error handling can be with In-App Purchase and in general with iOS. I consider the user experience to be the most important aspect of error handling. And the reality is that any operation that has complex networking and server side logic will probably have similar error complexity. And the side-effect of that is that a good user experience will result in complex code. I hope this post shows how I used ENUM’s and convenience initializers on NSError, UIAlertController, and UIAlertAction to help reduce the complexity and still deliver a good experience.

[iosdevbydesign]

In-App Purchases in Swift: Part 3

Summary

This is the third of many posts on handling In-App Purchases in Swift on iOS. The first post was a high level overview of how to read and verify the built in receipt. The second post was a review of the View Controller design and implementation for In-App Purchase. This post is going to be a lengthy code review of the CompletionHandler based purchase manager class that I made for Gratuity.

Apple Says Tsk Tsk

I wanted to make a Completion Handler based Payment manager. I wanted to do this because I think its really hard to do a good UI without a Completion Handler based API. The reason is that, when the user performs an action, you want to show something in the UI. When that action finishes, you want to change the UI back to how it was. Completion Handlers make this super easy. However, StoreKit is not designed this way. Believe it or not, Apple actually says in this WWDC 2013 video on StoreKit to not use a Completion Handler based API for In-App Purchases.

They make a really good point. They have set up SKPaymentQueue to throw transactions at your app at seemingly random times. That makes it hard do a completion handler API because an event, like starting a purchase, does not necessarily have a single result. SKPaymentQueue throws several events your way and you have to deal with them. The problem with their approach is it makes good UI’s really hard. And I think it shows. I think most iOS apps have very poor In-App Purchase experiences.

That being said, because my app only uses Non-Consumable IAP’s, I was able to build a Completion Handler based API. I can do this because I use the receipt to verify all purchases, not the transactions thrown at me by the payment queue. That makes it so I can take events that the view controller doesn’t know about and just “finish” them. Then later, I check the receipt for purchases and all is well. That said, if you’re doing Consumable IAP’s, then the only way to get a record of them is from the Transactions (because they are not in the receipt) so you have to pay much closer attention to Apple’s PaymentQueue.

Observing the PaymentQueue

StoreKit has a singleton object that our Purchase Manager is going to observe. The thing is that once you register your object as an observer of SKPaymentQueue, SKPaymentQueue just starts spitting events at you. Therefore, your View Controller should have control over whether you want the Purchase Manager to be observing the queue or not.

You can see that calling beginObserving() starts the observing. The endObserving() method is a little more complicated. During normal operation, the queue spits out events and then those events trigger the completion handlers and then the completion handler properties are cleared. When you end observing, the payment queue won’t send any events and therefore the completion handlers never get called or cleared. So the endObserving() method clears out any remaining completion handlers. This is important because the completion handlers hold a strong reference to the View Controller. This is bad because the View Controller also has a strong reference to this purchase manager object. That means you’ll get a retain cycle and neither the view controller nor the observer will ever be released from memory. Clearing the completion handler storage areas when you end observing solves this problem.

Receipt Verification

We already talked about receipt verification in the first post so I’ll keep this short. I designed this purchase manager object to be generic, then I subclassed it to make it specific to my app and my IAP. There is a simple method to verify the receipt of the App with RMStore.

Then in the subclass, I have more specific methods for verifying the IAP’s that I’m interested in. The View Controller uses these methods to verify if the purchase was made successfully or not.

Product Request

Before you can make any purchases, you need to request all the products you have from the App Store. A product is a single IAP. During this time, I show a “downloading…” message in the View Controller. I do this because I can’t initiate a purchase or show the price of the IAP until the product request is done. Read more about this in the second post.

I use a common pattern in this purchase manager object. I get a “thing” and a completion handler closure. In this case the thing is an SKProductRequest. I use that thing to store the closure in a mutable dictionary property using the thing as the key.

I then implement the callbacks required for the “thing.” In this case there is a callback with success and a callback with error. In both of those callbacks I get the closure out of the dictionary and call it with the necessary information. Easy.

Restore Purchases

Restoring purchases is kind of a wonky thing in iOS. I go over this more in the previous post., but its a required feature of apps that offer IAP’s. Its basically the only way Apple could think to be able to communicate with the App Store to restore a receipt. The reason it has to be explicit (and not performed in the background, invisible to the user) is the user may have to type in their App Store Password.

You can see this feature works in a very similar way to the product request feature in the section above. The difference is that only one restore process can happen at a time, so instead of a dictionary to store the completion handlers, I just have an optional property. Once the request is received, the completion handler is stored and the restore request is made. In the required delegate callbacks, I execute the completion handler and then clear it so there are no retain cycles.

Make Purchases

Making the purchase is a little more complex. For any single purchase request, several callbacks will be made on the “updatedTransaction:” delegate callback. I then check the state property of the transaction and only use the completion handler if its in a .Purchased, .Restored, .Failed, or .Deferred state. Otherwise, it just keeps waiting. And as before, the completion handler is cleared once its used to call back to the originating view controller.

I do one slightly janky thing here. If the updatedTransaction: delegate callback receives a transaction and I don’t have a completion handler for it, I just tell StoreKit that this transaction is “finished.” Finished is Apple’s parlance for “I took care of this transaction, the feature is available to the user, don’t tell me about it again.” Saying this transaction is finished is a bit disingenuous because I never did anything in the UI.

However, because I use the app receipt as the “single source of truth” for purchases I can do this. I can do this because, at the end of the day (if everything goes horribly wrong), I just check the receipt for purchases. I don’t need to care about each, individual, transaction. If you offer consumable IAP’s you should change this logic to so that “unknown” transactions are forwarded to an “all-knowing” class that can change your model or present UI to inform the user that their consumable purchase has been accepted and can now be used in the app.

Summary

Thats a lengthy overview of the Purchase Manager class I made. Its pretty simple but I think it makes handling purchases a lot more deterministic than the normal delegate callback method that Apple wants you to use. Just keep a note of its limitations and problems. This design works for my specific case. Which I should note: is a very common IAP use case. I find that most apps offer a non-consumable IAP to disable ads or enable a new feature. Thats what this purchase manager was designed to handle and its how I use it. However, if you have more sophisticated needs and/or more complex types of IAP’s you may need a different purchase manager design. All the code for this class can be found in a Github Gist. Feel free to use and modify to your heart’s desire.

[iosdevbydesign]

In-App Purchases in Swift: Part 2

Summary

This is the second of many posts on handling In-App Purchases in Swift on iOS. The first post was a high level overview of how to read and verify the built in receipt. This post is going to be a high level overview of how to construct the View Controller that will allow the user to initiate the purchase. High level means you’re going to see more concepts than you will code snippets.

Required UI

Dynamic Description and Price

Each In-App Purchase has a localizedDescription and price property that are set by you (the developer) in iTunes Connect. These can be changed at any time. This is handy because if you want to change the description or price of the IAP after you ship your app, you don’t have to submit a new build for review. This also means you should not hard code the description of the IAP into your View Controller. Instead it should be populated after downloading the IAP information from the App Store. Also, you MUST NOT hard code the price. The price will vary from region to region. Its set by Apple and can change at any time. Not to mention, you can change it yourself (as I mentioned above). The price of the IAP MUST be displayed and it MUST be populated dynamically after you query the Apple Store.

Restore Button

Your app must have a button to allow the user to “Restore Purchases.” I find this to be a strange iOS-ism. As a user, I don’t think its a very good user experience to have to tap on this weird “restore” button and then hope that my IAP’s come back. However, its something required by Apple. This restore button does not need to be on the same screen as your IAP, but it must be somewhere in your app.

Ugh, Async UI State Madness

All the App Store calls are network calls that are asynchronous. They are also really hard to keep track of so you can show user effective status. Be prepared to be changing constraints, hiding and show views, and doing all the other things that generally happen when a UI has to show a waiting state. Also be prepared to handle lots of errors. Basically… be prepared to build a Massive View Controller™ :(

I use a Swift enum to represent all the possible UI states. I added a property on my view controller that is of that enum type. This property becomes the single “source of truth” for the view. Lastly, I use property observer (didSet) to see when that enum changes and adjust the UI accordingly. This has many benefits. First, it makes me think about all the states ahead of time (required to create the enum). Second, it keeps all the View changes in one spot in my View Controller code. Third, it allows me to easily make sure I managed to reset all state in every possible UI State. Lastly, it makes changing the UI when performing and responding to network requests a one-line affair in all the numerous IBActions and completion handlers.

This UIState enum helps to stop the normal kind of UI state errors where one item is in a loading state and another item is in some other out of date state. We’ve all experience UI where the gray modal screen that stops you from clicking sticks around after it shouldn’t. The UI state enum helps reduce that possibility.

Handling Purchase / Restore

I’m not proud of the IBAction methods I ended up making for the purchase and restore buttons. The Restore method is 49 lines of code and the Purchase method is a whopping 65 lines of code. The unfortunate reality, is the there is just a lot of logic to go through when the App Store request finishes. Lets walk through the basic steps in logic.

0) Purchase Manager

The following steps are assuming you have a well built class that handles purchases and restores with completion handlers. Note that the built in StoreKit classes do not do this. They use delegate callbacks. Apple even recommends not using completion handlers because one request can cause many delegate callbacks. While this is true, I just don’t see how you can provide a good UI and User Experience for purchases without using completion handlers. There has to be a deterministic way to start a request and get a response. I think the way StoreKit is designed leads to the vast majority of IAP UI’s/experiences to be fairly terrible and confusing. We’re going to try to overcome that. In a later post, I will provide more details on how I designed the class.

1) Initiate the Request

When the user taps the button, we need to change the UI state to the loading state and also make the request. This should be two lines of code. In the first line of the completion handler, you need to change the UI state back to a normal (not loading state). After that there is a lot of logic left in the completion handler.

2) Check the receipt

First things first. Its time to see if they actually made the purchase. Your purchase manager class should have helper methods to load the receipt, verify it against the Apple certificate (as mentioned in the first post) and tell you if the IAP you were looking for has been purchased. Another reason we check for the purchase so early is because it helps with error handling logic.

If it has or has not been purchased, update your NSUserDefaults or whatever way you’re saving that information. Make sure it gets propagated to the WatchOS app or cloud service you use so the new feature will start working on all applicable devices.

If it has not been purchased, keep that stored in a local variable which will help with error handling logic later.

3) Check Transaction State (Purchase only)

When purchasing, you will receive an instance of an SKPaymentTransaction object from the App Store. The transaction has a property called state. If the transaction is in the Purchased, Failed, or Restored state you need to tell your purchase manager to finish the transaction. If you don’t do this, the App Store will keep throwing that transaction at your app all the time. Again, don’t worry if its failed, we already checked the receipt to see if the purchase had been made. For now, you just need to make sure to tell the App Store the transaction is “finished.”

If the purchase stat is Purchasing you have a tiny problem. Your View Controller should not see a transaction that is in the Purchasing state. You should adjust your purchase manager class to not call the completion handler block if the purchase is still in “purchasing.”

If the purchase is in the Deferred state, then you have a big problem and a decision to make. Deferred is the state a transaction will be in when parental controls have required that a parent approves IAP’s for their child. A transaction can stay in the Deferred state for hours or even days. You must allow the app to continue being used when its in this state. However, its up to you whether to allow the use of the IAP feature. In my app, I temporarily allow access to the feature when its in Deferred. Then on next launch I check the receipt to see if the purchase made it through or not.

3.1) Big Problem with Deferred

Another big hangup with Deferred state is that the finished transaction can come to your purchase manager at any time. This, basically, requires that your purchase manager object instance is around all the time and is able to draw arbitrary UI on your screen at any time. Both of these things I don’t find ideal. Having a screen randomly pop up on your user is not good. I want my app to be in a time and place where I know its time to handle transactions. Basically, what this means, is that Deferred purchases (once approved) may require the user to manually Restore purchases in order to get the feature.

Not ideal. I just saw no good way around it. Not to mention, Deferred is super hard to test. It requires creating many IAP sandbox test accounts on two real devices and setting them up in parental control mode over and over.

4) Check for Errors

There are lots of errors that can happen with IAP’s. iOS, in general, has system errors are pretty useless and cannot be shown to users (as opposed to Mac OS X errors which are brilliant and are very helpful for users). There are the normal set of network errors that can occur with a mobile device. On top of that you have to deal with other possibilities. For instance, with restores, the network request will succeed, but the user may not have made the purchase. At that point in time, its probably a good idea to tell the user that they need to buy the feature.

In a later post, I’m going to do a full overview of how to handle errors with IAPs.

Lastly, its important to not show errors at certain times. For example, don’t show errors when the user “Cancels” the purchase. When a user cancels, they know they cancelled and they don’t need to be reminded. Also, don’t show alerts when the purchase succeeds. When the purchase succeeds, iOS presents an alert that says the purchase was successful.

5) Update Analytics

This step is not required. However, you’re probably doing all of this work for IAP’s so that you can make some money. Generally, its a good idea to use some sort of Analytics system to keep track of this. Apple’s tools are slow and annoying. I use Crashlytics and it has built in reporting tools for purchases. But there is also Mixpanel and many other analytics tools that have really good iOS SDK’s. I suggest you use one :)

6) If everything went well

I close the view controller and load the feature they just bought. I think its a nice touch.

Summary

Sorry about all that. I know its a lot in one post. StoreKit and IAP are a very complicated API. There is a lot of state to deal with, there are a lot of errors to deal with. And even when everything goes well, there is still a lot to think through. Hopefully this post gives you an overview of the kinds of things you need to think about before you start trying to approach the problem.

The next post, which will be on building the Purchase Manager class. I was inspired by this old Ray Wenderlich post. They use blocks to make a completion handler based API for In-App Purchases and thats exactly what I did. Stay tuned!

[iosdevbydesign]

In-App Purchases in Swift: Part 1

Summary

This is the first of several posts on handling In-App purchases in iOS apps in Swift. These posts will be pretty high-level: there will be more concepts than code. For the big Gratuity update that I just submitted to the App Store, In-App Purchase was the single largest set of code that I added. I use the IAP to enable the Split Bill feature of Gratuity. I can assure you that the code to handle the IAP is far larger than the code for the feature. I would advise to proceed with caution if you want to add IAP. You should be sure you will make money from it because its tough.

So lets get started :)

Application Receipt

What is it?

The application receipt is the “single source of truth” for the purchase of the app from the App Store and for each Non-Consumable In-App Purchase. Non-Consumable is Apple’s term for an IAP that can only be purchased once and persists across devices and install. The opposite is a Consumable purchase. Those are for purchases that are more ephemeral. Think fake currency in a click-bait game: Those are consumable. Consumable IAPs are not in the receipt so you have to take more care with them. I only dealt with Non-Consumable IAPs. If you’re interested in one of the other myriad types, this post may not be super helpful.

Just remember, the receipt is the source of truth. I used that as a key part of my code. I designed the logic so that the receipt is checked during application launch. I also check the receipt whenever the user tries to start a new purchase or restore existing purchases. I also check the receipt again after any restore or purchase request finishes.≈

Wait! its missing‽

The receipt is not always there: this is normal. For example, when installing via Xcode (while debugging) its not there. Also, if the user installed the app by syncing with iTunes, its not there. So don’t write logic that requires a receipt. It is normal for it not to be there.

If its not there, you should allow the app to do as much as possible for your business model without the receipt. The more your app costs, the less you should allow without a receipt. The cheaper your app is, the more you should optimize for a smoother user experience without the receipt.

Once you have determined that you need the receipt to verify purchases before allowing the user to continue, you should present a view that allows the user to tap a “Restore Purchases” button. This is the only way to get the receipt from the App Store if it is missing.

Now, you’re asking “why do we need to present the user a screen? Isn’t it a better experience if we load this receipt silently in the background?” Well… you can’t. Restoring often times requires the user to put in their app store password or Touch ID. Obviously, this is quite alarming to the user. Also, if it happens during app review (another time that the receipt WILL be missing) then they WILL reject your app.

How Do I Verify the Receipt?

Apple provides no “built-in” way to do this. Apple says that they don’t provide this behavior because malicious people would be able to easily circumvent all receipt validation. This is definitely true. However, it makes it pretty hard for a normal person, who probably has little to no security concerns, to do this on their own. I would have preferred an easy built-in system that beginners could use and professionals could ignore.

The receipt is saved using industry standard encryption formats. But just because they’re industry standard does not mean they are easy to deal with. Swift makes this a little harder because its newer and there is not as much stuff out there for handling encryption keys. Also, the standard OpenSSL project does not appear to work with Cocoapods and Swift.

Luckily there is a working OpenSSL Swift Library from krzyzanowskim that can be included in your Podfile. Then there is an open source project built for handling In-App Purchases called RMStore. This can’t be included in your Podfile because it requires the official OpenSSL project which I couldn’t get to build. Also, most of the framework is for handling purchases instead of verifying receipts.

I installed the smallest portion of RMStore .h and .m files into my project in order to verify receipts. The file I ended up including in my project are below:

But wait, RMStore Sucks at Verifying Receipts

This is true, but it can be made better. By default, RMStore loads the Apple Receipt Certificate from the App Bundle. If the certificate is not found, RMStore just return YES to the receipt being valid. Obviously I didn’t want this. So I changed the logic so if the receipt was NIL, the validate receipt method would return NO.

Then, just to be safe, I obscured the certificate in a string in the code. So instead of RMStore loading the certificate from bundle, I had it load the certificate from a string that I hardcoded into RMAppReceipt.m. This is totally optional, but it makes it so that a would-be pirate can’t simply replace the Apple certificate in your bundle with a certificate they made that verifies the false receipt they also made.

RMStore is Crashing My App

This also happens. Objective-C code without nullability annotations imports all types as implicitly unwrapped optionals! This is bad, because they cause crashes. Make sure to if let all the return types. Or you can follow the instructions at NSHipster to mark all types as NULLABLE.

Ok, the receipt is verified, where are my IAPs?

The RMStoreReceipt object can give you an Array of RMAppReceiptIAP objects. You need to get that array and then iterate through it. For every receipt inside the array, you can check if they have the same identifier as the IAP that you’re interested in. If so, then the item has already been purchased. If not, then the receipt shows no evidence of the IAP having been purchased by the user.

This verification is how I verify the user has purchased the IAP. I check it on launch, I check it when a user initiates a purchase / restore request. I also check it when a restore / purchase request finishes. I find this the easiest, most reliable way of verifying Non-Consumable IAP. Again, for other type of IAP, you may need more complicated logic.

How do I Ask the User to Buy Something?

Setting up the View Controller took a while. Handling the edge cases took even longer. This is coming up in the next blog post.

[iosdevbydesign]

Making a Mac App

This post will be a lot longer than normal. Its a very high level collection of experiences I had when writing my first Mac App. The app is called Cartwheel. Its a GUI on top of Carthage. Its far from done, but its totally open source and I will happily accept critique and pull requests :)

Mac OS X and iOS share a lot of their internals. Foundation, Core Image, AV Foundation, Grand Central Dispatch, NSURLSession are all shared and their API’s are almost the same between the two platforms. The notable exception is UIKit vs AppKit. These are the UI frameworks and they’re both pretty different. This is partly necessitated by the fact that AppKit is built for mouse input and UIKit is built for multitouch. That being said, there is also the elephant in the room: time. AppKit has been evolving since 1989 on NeXT systems whereas UIKit was a reboot started somewhere in the mid 2000’s. While UIKit shares the general style of AppKit, AppKit has a lot more power (which means complexity) and a lot more cruft leftover from the old days (which also means complexity).

NSWindow / NSWindowController / NSViewController

While iOS has a UIWindow, its something you don’t really interact with. A single UIWindow is created for you, then you fill the it with a UINavigationController and then you stack UIViewControllers within the UINavigationController. On OS X, things are a bit more complicated. You can have multiple windows. Each window should be managed by a single NSWindowController.

The NSWindowController helps configure the window’s appearance and handles the window lifecycle. On top of that, OS X has an NSViewController, but its a little different than iOS. Each NSWindowController can and usually does contain multiple NSViewControllers. For instance, the NSWindowController has a special slot for an NSTitlebarAccessoryViewController that holds a custom Toolbar. On top of that, its best to create an NSViewController subclass to control the main view in the window. So generally, each NSWindowController contains two NSViewControllers. That means instead of the iOS standard of 1 UIViewController to 1 “Screen,” OS X has 1 NSWindowController and 2 NSViewControllers to 1 “Screen.”

This may not seem like a big deal, but on OS X you really need to have a better understanding of how to safely communicate from these different objects in order to get an app that runs without crashing and without memory leaks.

What are Files?

LOL. The basis for the computer programs we all know and love since the beginning of personal computing, files and the filesystem, is something you basically don’t have to deal with in iOS. Well, in OS X, you have it and you should love it and embrace it. But don’t abuse it. Its perfectly simple to create a NSURL with a file://~/Documents/Whatever path. But don’t do it! You never know if Apple will move one of those folders and it won’t work if you sandbox your app. The Mac App Store requires your app to be sandboxed, so its no joke. Instead, use NSSearchPathForDirectoriesInDomains to get a path to the Application Support folder or the Preferences folder or the Documents folder. When you want to append onto that URL, use NSURL method URLByAppendingPathComponent. On top of that, if you want to open a file that is outside your sandbox, remember to use NSOpenPanel and/or NSSavePanel to let the user select it.

The big question is how to read and write data from and to the disk. OS X has NSFileManager and NSFileCoordinator. If you’re going to be reading and writing files that other apps, cloud services, etc may also be reading/writing to simultaneously use NSFileCoordinator (and good luck). If you’re going to be doing lots of reads and writes, use NSFileManager. I have used this in my DataSource class. Its pretty easy, but its not the easiest way.

The easiest way (shown above) is just to use NSData and other foundation classes. NSData, NSString and NSImage all have methods to write their contents to disk. You just have to pass them an NSURL and they do the rest. They all also have class methods that attempt to initialize them from an NSURL on the disk. Thats seriously the easiest way. If you’re worried about file size and speed, use Grand Central Dispatch to put them on a background thread.

NSTableView

NSTableView and UITableView sound similar. But oh my. UITableView should have been called UIListView. It lacks the key component that makes tabular data… tabular. UITableView has no concept of Columns. That may seem like no big deal, especially if you only want NSTableView to show a single column. But its a bigger deal because UITableView has UITableViewCell that represents each line in the table. NSTableView has NSTableRowView and NSTableCellView. The RowView is responsible for handling (and drawing) selection of the entire row (which could encompass multiple columns and cells). The CellView acts more like UITableViewCell. That means that, similar to Windows in AppKit, the Table Cells in AppKit also have 2 objects that represent a single “cell.”

That being said, both UITableView and NSTableView share methods that are very similar for registering NIB’s for cell/row reuse. They also share very similar delegate methods for asking for cells. The difference is with NSTableView there are two of them. - (NSTableRowView *)tableView:(NSTableView *)tableView rowViewForRow:(NSInteger)row for the NSTableRowView and - (NSView *)tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row for the NSTableCellView.

Legacy

Error Handling

Most of the iOS API’s I dealt with handled Errors via a callback closure. Maybe thats because on iOS I was mostly dealing with network requests? In any case, on OS X I had to get used to a different style of Error handling: using NSErrorPointer. I know iOS uses this as well, but It seemed far more prominent in OS X. The idea is that you create a reference to an optional NSError. Then you pass that reference in with the operation you are trying to perform (with the weird & inout Swift syntax). After the operation is complete that reference to the optional NSError could either be NIL or have an error. You then check if there is an error and handle the error, if its NIL, the operation is presumed to have succeeded.

NSTableView Row Height

In iOS 8, Apple introduced UITableView cell automatic height determination. Needless to say, they have not done this for NSTableView. With NSTableView you have to manually return the height of each cell in - (CGFloat)tableView:(NSTableView *)tableView heightOfRow:(NSInteger)row. In my app, I draw a single cell offscreen. Then for each row, I change its contents, force it to layout and then grab its height and return it to the TableView. Its very similar to how I’ve done it before on iOS 7 projects. Its just a little bit annoying that OS X has had Autolayout for longer and has a lot more powerful CPU to do this kind of stuff for us and Apple still hasn’t implemented it on OS X.

Interface Builder

I have a lot of opinions on NIB’s. At first I thought they were really great. However, over time I have grown less in love with them. I could write an entire other post on NIB’s (and probably should). For this post, what is important is that this Mac OS X app I am working on was going to be my first App that did’t use NIBs. I was planning to draw everything in code and do all the auto layout in code. In iOS this would be easy. UIViewControllers can be instantiated without NIBs. UITableViewCell classes can be registered to UITableViews as classes rather than NIB’s, etc. In OS X, this is basically impossible. Creating an NSWindowController and an NSWindow without a NIB is possible, but you lose all the default behavior of windows. Default behavior includes remembering size, position, full screen state, minimized state, etc. Same with NSViewController. They can be created without NIB’s, but it requires a lot of work on your part. So what I ended up doing was creating all the NIB’s I needed to make all my Window Controllers and ViewControllers and just leaving them blank. So I have a bunch of NIB’s sitting in my project that just do nothing. I’m not super happy about that.

NSNotificationCenter

In iOS there are a lot of methods you override in order to respond to system events. Examples include rotation/size class changes, viewDidAppear, shouldPerformSegue, etc. OS X has a lot fewer of these built in methods and instead tends to use NSNotificationCenter to respond to events. This approach is a little more complex because you get an untyped UserInfo dictionary instead of a well defined method signature. But it also makes a lot of sense. As I said before, you have a lot more objects floating around in OS X and having pointers between them all would be a nightmare. So instead of the NSViewController having to know about the NSWindowController that it sits within, the NSWindowController can just register the NSViewController for Window lifecycle events like DidBecomeMainWindow. NSNotificationCenter is really good this way. Its also scary to think how easy it is in Cocoa to register some instance of some class to a new notification and then have the app crash when it gets notified. Also, remember to de-register notifications when an instance deallocates or else you’ll get random crashes all over the place. Aren’t unsafe unretained pointers fun? :)

NSAlert Gem

So a lot of this has been a little bit complainy. So, let me show you something that made me incredibly happy! NSError gets a bad rep by iOS developers. Its overly elaborate, it has indecipherable domains with indecipherable errors and it gets all messed up by third parties when they get their mits on it. Also, all the information has to be manually extracted by the developer and presented to the user. Well, OS X has an absolutely amazing NSAlert class. It has an initializer that just takes an NSError. NSAlert(error: NSError). Then when you present the NSAlert to the user, it does all the hard work of parsing the NSError and giving usable information to the user. Its absolutely incredible.

[iosdevbydesign]

Watch Performance Testing. Its pretty much impossible, and I’ll tell you why. But first we need to remember the core components that make up a WatchKit application. 

The iOS App. 

This is the heart of your user’s experience. It runs on the phone, it download data from the network, it crunches numbers, it detects motion, etc. This is what we all think of as apps.

The iOS App WatchKit Extension. 

This is a small app that runs on your user’s iPhone when your user launches your WatchApp on their watch. This is the thing you are programming when you are working in Xcode on your Watch app.

The Watch “App.”

I put App in quotes because this app runs none of your code. This is the storyboard and image assets present in Xcode. When your iOS app is installed to your user’s iPhone, this Watch App bundle is then also installed (wirelessly) to your user’s Watch.

Its important to remember this distinction because when you do performance testing during Watch App development, you are doing performance testing on item 2 in the list. You are testing the performance of the WatchKit Extension that is running on your user’s iPhone. Not what they are running on their watch.

This is a problem because iPhones don’t have trouble loading 200 really basic UITableViewCells into memory. (I know they don’t do this anyway because of DequeReusableCell). But the point remains that the bottleneck on your Watch app is probably not going to be the iPhone, its going to be the Watch. 

The Watch “App” is basically a smart external display for the Watchkit Extension. When you load a table of 200 items onto the watch, your WatchKit Extension is producing 200 Table Row Controllers and quickly sending those 200 rows one by one to the Watch wirelessly with no idea when they finish (as far as I can tell). Since you have no callback when they finish, its almost impossible to do performance testing. When your WatchKit extension finish loading 200 rows and sends the rows to the Watch “App”, your WatchKit extension thinks its done all of its work and all of its state has been changed, yet the Watch still hasn’t updated its display.

When I did performance testing, making the rows, configuring the rows and then sending them to the display took the iPhone only 0.2 seconds. However, the watch took at least 3 seconds to actually update its UI. I say at least 3 seconds because there is no way to time it except with (ironically) a stopwatch and a keen eye.

Luckily, it seems the Watch is very good about doing these commands in order. So in my case, I send X number of rows to the watch and then tell the loading animation image view to hide. This always happens after the rows finish being sent to the watch because my WatchKit Extension send the hide command after the row commands. 

Also, I’m not supposed to say this because I went to [REDACTED] labs. But the Simulator does a very good job of emulating the connection speed between the WatchKit Extension and the WatchKit App (display). That means that you shouldn’t have to be too worried about your app being way too slow if you don’t get to test it on hardware before launch day.

[iosdevbydesign]

Advanced InterfaceController loading animations. By default, WatchKit Interface Controller loading is pretty bad. Its just a generic spinning thing that sits there until willActivate() finishes. Play the video above. The default behavior is the left most interface. I found a secret weapon to stop this behavior. There is a strange checkbox for each Interface Controller in the Storyboard. Its called “Hides when Loading” and its checked by default.

Unchecking this causes the Interface to show the storyboard verbatim until willActivate() finishes. This gives you the ability to show an empty version of your UI and then populate it with willActivate(). Because my interface is a table and I saw no way of easily building a placeholder table in storyboards, I put a new group that takes up the whole screen. It has a background image that matches the app. Then in willActivate(), at the very end, I hide the image and show the other interface elements. This is the middle screen in the video above. 

However, I really wanted something more. I created a step by step animation for an indeterminate loader. I then put that image in the storyboard and started to animate it at the very top of willActivate(). However, the animation wasn’t starting until willActivate() finished. This was a problem because I wanted the loader to spin while willActivate() was doing its thing. I broke out most of willActivate() into a private function. Then in willActivate(), after I start the animation for the loader, I call that function on a background thread. That function then does the appropriate work that it needs to do. The function also calls back to the main thread before touching the UI. The screen on the right shows the effect.

The effect is a big improvement. The default loader lets the user know that something is happening, but its not branded. The middle solution is branded but doesn’t let the user know that work is being done. The advanced solution satisfies both of these problems. Also, it seems like the generic spinner is also used when the Watch has a bad connection to the phone and they are trying to communicate. Using your own loader will also train the user that the generic spinner happens when things might fall apart. Whereas your loader will happen when things are working normally.

Click to see the full animation on its own.

[iosdevbydesign]

Hedging my bets with Apple Watch. No one knows exactly how Watch will work. Specifically, we can't simulate how the digital crown works. In Gratuity for iOS, I use long tables of numbers to allow the user to choose Bill Amount and Tip Amount. Well, if long tableviews don't scroll with the digital crown, then that will be a less than stellar experience. Flicking through a long list on that small screen will really suck. So I built a fallback UI. The fallback UI has 3 buttons you can tap on. Each button represents either the Hundreds place, the tens place or the ones place of the Bill Amount. Once a place is selected, a stepper UI can be used to increase or decrease the amount. The problem is, the app is already shipped, how do I change the UI? 

What I did is I configured the iOS app and the Watch app to check, on launch, a JSON file on my server. This JSON file tells it which interface to use. Once the JSON file is downloaded and parsed, it is written to an NSUserDefaults shared container. Its important to note that the download of this file does not stop launch. The Watch will launch into the UI on disk. All this download does is change whats written to disk. So that on next launch, it might have a new interface.

In any case, I think its a pretty clever idea. Take a look at the video, you can see how simple it was. Note that the UI's shown in there are basic and unstyled. Hopefully, I can make them look better. Also, the screen capture dropped a few frames when showing the fallback UI. Sorry about that. But I had already tried to record this thing about 6 times and I was done repeating myself.

[iosdevbydesign]

Switching Gears for a Bit. I started working on an idea I've had. Its dumb because its a social idea which means people need to use it for it to be useful. But I just like the idea. The full story is on my Github but the basic idea is that we can make a Twitter-like Microblogging platform without relying on Twitter, FaceBook, App.net, Ello or any centrally controlled system. We can recycle the principles of the classic web, blogs and RSS to create a Twitter-like service that is decentralized and where users control all of their content.

What I wanted to post about today was the "Value-ization" of all the types in my project. In Objective C the default way to make custom data types is to define a class that is instantiated into many objects. This is an object type. The problem with objects is that they are "alive" and can change right out from under you without you knowing. The other type is Value types. Value types are "dead." They don't change out from under you because each Value type is under the control of exactly only one other Object or Value. In swift, Value types are very powerful. This is why the built in types in Swift are Value types instead of Object types. This is the opposite of Objective C, where even the simplest types are Object types (e.g. NSString). I was convinced of the power and safety of Swift Value types during a presentation by Andy Matuschak.

In this PicoBlog project I've been working on. I had value types that represented the data I needed (Subscriptions, Messages, Users, etc). However, each of their properties was generally an Object Type (NSString, NSDate, NSURL, etc). The work I did today replaced all of those Object types with custom Value types. The problem with using Value types to represent NSURL and NSDate is that many parts of Cocoa require those specific object types. 

To get around this issue, I used protocols and optional initializers to require that my custom Date and URL types would be guaranteed to produce an NSURL or NSDate without actually storing an NSURL or NSString. The screenshot above show how I use the URLVerifiable protocol to make sure my VerifiedURL type is guaranteed to produce a valid URL object once it has been successfully initialized. In short, when initializing the Value Type, if the given string can’t be converted to an NSURL, the initialization fails and returns NIL. Its up to the Value type that created that VerifiedURL type to determine what to do with a failed URL. All of these concepts were new to me and they get into some tricky swift syntax. Luckily my good friend Michael Helmbrecht was there with good idea to help me moving forward.

The last protocol I created for all these custom types was Writable. This protocol requires that each type can be converted to NSString in an NSDictionary and can be initialized from an NSDictionary of NSStrings. This is required for two things. NSUserDefaults is an easy way to store small amounts of information to disk on iOS. NSUserDefaults has very limited type support and does not include support for Swift Structs at all. So converting everything to NSString and NSDictionary is required. The same is true for NSJSONSerialization, which I use to read and write JSON files. JSON is even more limited, so the NSString and NSDictionary compatibility is key. By making the types conform to the this protocol, its easy to read and write all of these custom Value types to whatever place I like.

This project is free and open on my Github. If you see something shitty in my code or have an idea, submit a Pull request. I'd love it!

[iosdevbydesign]

SKTextures now regenerate when zooming in or out. This was pretty simple to accomplish. All of the planets are embedded in a Subclass of SKSpriteNode. This subclass monitors the xScale and yScale properties. When they are changed, it iterates through the array of all its children to inform them that their parent changed its scale.

I didn't want new SKTextures to be generated every time the scale changed. The scale will usually change many time per second, so generating textures at that rate would be silly. So instead, I use an NSTimer system to wait for the scale to stop changing before generating a new SKTexture.

Once one of the planets receives a new scale, it checks to see if the NSTimer property has been set. If it has, it does nothing. If it hasn't it creates a new NSTimer object.

The NSTimer checks to see if it should wait for more changes in the scale. If it should wait, it changes the shouldWait property to false so that the setScale function can change it back to true. If the shouldWait property is false, the timer invalidates itself (to remove any strong references) and then changes the property to nil. At that time it updates the SKTexture with the new scale value (not shown).

This seemed like the best way to allocate the minimum number of NSTimers needed in order to accomplish the same effect as regenerating the texture after every scale change.

[iosdevbydesign]

The UIPanGestureRecognizer took me a long time because I had never used Gesture Recognizers like this before. However, the UIPinchGestureRecognizer and the UIRotationGestureRecognizer were very easy to implement because they work in basically the same way as the UIPanGestureRecognizer. 

Each gesture recognizer has a Property on the class that helps it keep track of where the SolarSystemNode was when the gesture began. Then as the gesture is changing, it uses this starting point as a baseline to go on.

By default only one gesture recognizer can work at a time. However, the optional gesture recognizer delegate can perform logic to determine if two or more gesture recognizer can work at the same time. The method is called gestureRecognizer(gestureRecognizer: UIGestureRecognizer, shouldRecognizeSimultaneouslyWithGestureRecognizer otherGestureRecognizer: UIGestureRecognizer) -> Bool. I always just return true so they an work at the same time.

However, this created a bug with the UIPanGestureRecognizer. If you have two fingers on the screen (to do a pinch or rotate gesture) and then you lift a finger up and place it down, the UIPanGestureRecognizer  doesn't know which finger to track and it causes the node to jump from one finger to the other. So I had to change how the recognizer logic works. Before I was always using func locationInView(view: UIView) to find out where the users finger was and then move the node around. However, UIPanGestureRecognizer also provides func translationInView(view: UIView) which returns only the change from the original locationInView. So I created another property that is set when the gesture begins with the locationInView. Then in the changed state, I use the original starting point plus the tranlationInView to figure out how much to move the Node. That way when the finger changes (and this the location in view) in the middle of a pan gesture, the Node doesn't "jump" from one finger to the other.

As you can see in the video, its impressively smooth. Next is to make the nodes regenerate higher quality imagery when they are zoomed in.

[usesmagnets]

[iosdevbydesign]

I got panning working! I know these innocuous looking lines of code seem simple. However, this is the first time I have ever used a UIPanGestureRecognizer at all, let alone in SpriteKit. I have always gotten away with UITapGestureRecognizer or UISwipeGestureRecognizer. Those are super simple because they work more like a button. When some qualifications are met, they call a selector on their target. Then you perform the action you want like a view appearing or disappearing.

With SpriteKit I had to first figure out how to pan the nodes. It turns out SKScene (where all the SKNodes live) doesn't really liked to be moved around. It has an anchorPoint property that can be changed, but its a bit strange to work with. Its a CGPoint where each value is between -1 and 1. SKNodes on the other hand have a position property that is a normal CGPoint that uses points based on its SKScene coordinate system. So the first thing I had to do was create a "SolarSystemNode" that was the size of the scene that all of the planet nodes would go into. This was pretty simple, but it required me changing some of the math so the Sun and the planets still knew how to appear in the center. Once that was done I could start playing with the position of the SolarSystemNode with the gesture recognizer.

The UIPanGestureRecognizer is tougher because the selector you give it is called over and over again with very little context. So when the state of the gesture recognizer is began you have to set up the context in a property and then when the selector is called over and over in the "Changed" state, you use that context and the information from the gesture recognizer to perform the pan.

Its pretty simple after reflection, but because I had never done anything like this, it took me a few hours :p. Next is pinching to zoom in and out.

[iosdevbydesign]

A new way for planets to orbit. A coworker showed me how I can use Sines and Cosines to accurately move an object in a circle. I totally threw out my old code with the Joints and the impulses. 

Now I just have a timer that executes a function that does some math and tells the plan to move to the new location. The great thing about this is I can control how often the timer is fired and the planets always move to the right spot. This is better than the old code which was called every frame.

I also use NSDates to calculate how long its been since this function was called and adjusts for it. This does 2 things. First, it lets me change the timing on the timer and the rotation of the planets stays the same speed. The rotation of the earth takes approx 18 seconds now matter what the timer is set for. It just moves in a more "Stop sign" shape if I set the timer to be too slow. Second, if frames are dropped, it will take that into account and the planets will move to the correct spot despite the code not being called. For example. I can set a breakpoint and stop the simulation for a few seconds. When I continue execution, all the planets move to the spot they should have been in if I had never hit a breakpoint.

[iosdevbydesign]

I've been playing with SpriteKit and its physics engine. I thought a first easy step would be to build a little Solar System. I'm not super concerned with accuracy or making sure all the planets move at exactly the right speed. I just wanted to get planets (Nodes in SpriteKit parlance) spinning around the sun. The first hurdle was that the SpriteKit physics engine doesn't cause individual nodes to have their own gravity based on their mass. So Nodes can't float towards each other. The second hurdle was that the gravity on the scene can be set but you can't change the center of gravity. Gravity always goes towards one edge of the screen.

So I thought the next thing I would have to do is "Add an Impulse" which pushes the Node in a direction. I could do the math to make sure that impulses that occur every frame would push the planet in a direction so that the distance from the sun was always maintained. I couldn't even begin to think about how complicated this math would be :-/

Instead, I found out about SKPhysicsJoints with can attach two Nodes to each other. So now I use a joint between each planet and the sun. Then I apply impulses and the distance is always maintained. I just have to check the location of the Node to make sure I'm pushing the impulses in the right general direction. It works pretty well, but I'm worried it will be too inflexible later.

Next is to make pinching for zooming in and out work on the solar system.

[iosdevbydesign]

Gratuity was accepted into the app store! Yay. This is always so exciting. It kind of makes iOS development special. While I would always vote to get rid of Apple as the gatekeeper to iOS, it definitely builds suspense as a developer. I find myself constantly asking things like "Did I choose all the right options in iTunes connect?" "Will it crash while they're testing?" "What if they just don't like it?" Luckily, its a pretty smooth process. It sits in "waiting for review" for 5 days or so. Then you'll get a notification that its "in review" and then 24 hours later its in the store.

Of course, once it hit the store, I found a bug that I couldn't test until it was in the store. When apps have a link to themselves in the store (usually for reviews), you can't test it until its in the store. And of course, I got the link slightly wrong. So that was annoying. I had to build a new build, submit it to the store and explain the situation. Luckily, it appears their algorithm bumps quick resubmissions to the front. It went into review a day after re-submission and was updated in the store 48 hours later. I know this is faster than normal because right after I submitted that, I submitted a bug fix update for my other app and its still waiting for review. Days after Gratuity was already updated in the store.

So make sure to download it and give it a 5 star review!

[iosdevbydesign]

Setting the color of the Circular thing that is used to control the slider should be easy. Apple provides a setThumbTintColor method. However, it simply doesn't work. You set the thumb tint color as many times as you want and it stays white. If you search online, Stack Overflow says that you can set an image for the thumb and then set the tint color and it works. This workaround does work, but it causes the thumb to look like iOS6. It has a gradient and shadow, etc. Its very ugly. I have a screenshot of the workaround. It appeared the only solution would be to create my own image and use that for the thumb in the slider.

This presented a problem for me. I don't like using bitmaps in my projects because they are pain to change whenever I change something in the app. If I decided to use a different color a different line thickness, I have to go through and update the bitmap assets. What a pain. So this was an opportunity to learn how to use core graphics to create a UIImage.

I, of course, used my favorite new thing... Lazy Properties. To create this UIImage. That way all the code for it is stored within the property itself. Its not spread around my code. It is still an optional property because UIImages created by Core Graphics are also optional. But I've never had it not work. Also, a friend brought up that this takes way longer than loading an image. I used NSDates to track how long it took to do this. Even on an iPhone 4S, it took less than 1 thousandth of a second. I'm happy with that. Lastly, because I am using Core Graphics, I took the opportunity to make something that looks cooler than just a Red Circle. Now I have this really cool looking red circle stroke that looks great in the settings screen.