Brent Simmons starts with Swift. And just as I, he struggles with value types, protocols, and generics: once a protocol references another or has a dependency on Self, you cannot use it as a type constraint or placeholder for all descending objects. You either have to use generics to expose a variant for each concrete type, or you re-write the protocol. There’s no equivalent to the way Objective-C did this: something like id<TheProtocol> just doesn’t exist. Swift is stricter. So how do you deal with that?
I’m writing unit tests for my Storyboard-based view controllers. Button interaction can be tested in view automation tests, but that’s slow, and it’s complicated, and it’s not even necessary for most cases. To write unit tests instead of UIAutomation tests for buttons, you test multiple things. Here are the tests.
I like when the code is explicit. Unlike Brent Simmons, I don’t feel comfortable using string literals in code especially not when I’m still fleshing things out and change values in Interface Builder a lot. In Objective-C, I would’ve used plain old constants. For storyboard segues, for example:
After working on the model of your app for a while, it can be hard to change your ways of thinking and see what should be coming next. How does an app come out of all this? Where does the user interface plug in? It helps to architect your app in layers and focus on the missing parts before figuring out the glue.
Freemium is said to be a popular way out of the iOS App Store underground. Make your app freemium and skyrocket your downloads. Then sell cool stuff from within the app to unlock more features or buy expendable contents and services.
This doesn’t work for all things on the market, of course.
Why did Shuveb’s app make less money with freemium than with a paid-up-front sales model? That’s hard to find out without more experiments, but unlike in science, I guess you can only have that many trials in the App Store before users stop to trust you.
Shuveb himself said multiple times that his app is really really niche-specific. His freemium model allows people to convert one article to Kindle per day for free; more cost money. Maybe his users need no more than one article per day, maybe often times even less. That’s possible but hard to say without analytics about usage patterns from within the app.
Even with app analytics, how can you find out usage patterns if people know they have only one shot per day and probably don’t open the app more often than that?
You can only compare to data from the less limited intro phase. Do users stop opening the app regularly after they converted their first 3 articles?
Read Stuart Hall’s experiments with the vastly more successful 7-Minutes workout app. He switched to In-App Purchases and people loved it. He found folks liked buying features less than buying additional content. I try to keep that in mind because it makes sense, but then again, I’m probably biased towards the good story.
Finding out how to make money with iOS apps is pretty hard. Actually making money is easier if you have a huge following of people you can market to. It’s easier with a network of bloggers and journalists. It’s easy when your app doesn’t actually suck.
Well, of course it’s easier if it isn’t hard.
I believe in value of the craft. I have to in order to stay sane. But crafting alone doesn’t feed hungry mouths. It merely keeps me happy. We need a market, and we need to reach it, and we need to deliver timely. There’s a lot of uncertainty and pressure. Making apps freemium from the get-go might not solve any of our problems. We have to think twice about it, you and I and all the other indie app devs. And maybe hope for a niche of professionals who are willing to pay more. (Which is the other popular promise how to become successful.)
Objective-C got generics! No more collection classes just for the sake of guarding against invalid elements!
I used custom collection classes a lot for the Word Counter to let the compiler help me prevent mistakes. Swift generics were a godsend for that kind of safety. Now, Objective-C can achieve similar awesomeness.
Now the compiler will warn (!) you if you misuse it:
Vehicle *car = [[Vehicle alloc] init];
[car.wheels addObject:@"NSString is of the wrong type"];
Great news, since if you didn’t spend a lot of time creating custom collection types yourself, now at last can you ensure array element type consistency. Makes your code cleaner and more reliable.
Throwing exceptions and being able to catch them is awesome news. Then there are cases which can be handled with try-catch technically, but shouldn’t. Think about this: in what cases could you make use of that? And what are the consequences for your work? For example, Erica Sadun points out that accessing array indexes out of bounds as a subscript will still crash the app since you can’t catch that kind of exception (yet).
You don’t have to learn anything new if you work with Core Data in Swift. It’s a pain to use NSManagedObject directly, so you better work with custom subclasses all the time. Unboxing optional NSNumbers is just too cumbersome. There are caveats you should be aware of, though: Swift’s static typing makes it a bit harder to write test doubles for managed objects.
Mocking and stubbing in tests is useful to verify behavior and replace collaborating objects with simpler alternatives. Since Swift is statically typed, you can’t use a mocking library anymore. But it’s trivially simple to write simple mock objects as subclasses in place:
