24 hours after the big September 2014 Keynote. We’re now living in a world where the new iPhones have a 4.7 and 5.5 screen and the rumors about the Apple wearable are no longer rumors.

But now it’s also possible to submit Apps written in Swift to the App Store. With this in mind, the awesome people over at Objc.io released a new issue of their so-called “periodical about best practices and advanced techniques for iOS and OS X development”. It’s all about Swift. Go read this and every issue before, it´s totally worth it.

I started playing with Swift the day it was released at this years WWDC keynote. I created dozens of playgrounds and example projects and Apps exclusively using Swift. But now I finally started using Swift in Mentio. I plan on writing every new class in Swift, thanks to the way the language is implemented, it’s absolutely no problem to use Swift classes/methods in Objective-C and vice versa.

The most “challenging” part is to make sure Xcode created a bridging header, in which you import all your Objective-C files you want to use in Swift. On the Objective-C side, import the Swift header, to make your Swift code available to the old and crufty pointer-code. For example in Mentio: import "Mentio-Swift.h"

That’s it.

Today was my first day of the internship. This is the first time I’m working for a real company, on real products, with knowledge I’ve gained through my studies. Quiet exciting.

I’ve started working on Mentio version 2.0 and I’m changing the business model to a freemium approach, this means the App will be free, but you can unlock features buy an in app purchase. Customers who bought the App before the release of 2.0 will receive the extras for free, because I will include features, which were included in previous versions.

In order to implement this I need to know which version of the App the user originally bought. Since iOS7 this is possible without the use of a separate account system and can be done local on the device. Apple published a Programming Guide to validate the Appstore Receipts and to extract metadata like the original App version. There are even some fantastic 3rd party libraries out there: RMStore, VerifyStoreReceiptiOS

On purpose Apple did not release demo code on this subject, so everyone uses a different approach to implement the receipt validation in order to prevent bugs that will affect tons of Apps.

Obtaining the receipt

The only problem is, obtaining this App receipt isn’t as straightforward as I thought.

NSBundle.mainBundle().appStoreReceiptURL returns an NSURL describing the path behind which the receipt can be found, if there is one!

To quote the documentation:

For an application purchased from the App Store, call this method on its application bundle locate the receipt. This method makes no guarantee about whether there is a file at the returned URL—only that if a receipt is present, that is its location.

But how do I extract the original App version number if there is no Appstore receipt?

In such a case, you have to start a SKReceiptRefreshRequest. This tries to download a receipt and saves it in the known destination if everything succeeds.

An example Swift implementation to obtain a receipt, if there isn’t one, could look like this:

class AppStoreReceiptObtainer: NSObject, SKRequestDelegate {

    let receiptUrl = NSBundle.mainBundle().appStoreReceiptURL

    func obtainReceipt() {
        var fileExists = NSFileManager.defaultManager().fileExistsAtPath(receiptUrl.path!)

        if fileExists {
            println("Appstore Receipt already exists")
            return;
        }

        requestReceipt()
    }

    func requestReceipt() {
        println("request a receipt")
        let request = SKReceiptRefreshRequest(receiptProperties: nil)
        request.delegate = self
        request.start()
    }

    //MARK: SKRequestDelegate methods

    func requestDidFinish(request: SKRequest!) {
        println("request did finish")
        var fileExists = NSFileManager.defaultManager().fileExistsAtPath(receiptUrl.path!)

        if fileExists {
            println("Appstore Receipt now exists")
            return
        }

        println("something went wrong while obtaining the receipt, maybe the user did not successfully enter it's credentials")
    }

    func request(request: SKRequest!, didFailWithError error: NSError!) {
        println("request did fail with error: \(error.domain)")
    }
}

Make sure you have signed out of your iTunes account in the Settings.app and use an iTunes test account for all of this.

Thanks to VerifyStoreReceiptiOS; I would probably still read the documentation and try to find something on Google without it.

I finally got to try Mailbox for Mac and it got me to use the App full-time on both, the Mac and iOS (E-Mail clients is a topic I’m incredibly angry and furious about, I think I have to explain my thoughts about this in another post). As we all know, Dropbox now owns Mailbox and this made me think, if it’s a good idea to use a product of a company, which is seemingly under extreme pressure.

In the past weeks a lot negative thoughts about Dropbox floated around. For some it’s way to expensive in comparison to the competition, for others it’ll be redundant with the release of iCloud Drive in OS X 10.10 and iOS 8. For me, all those points aren’t valid at the moment. I don’t see myself sending all my documents, images and encrypted passwords to Google or Microsoft, nor do I trust Apple to reliable sync these files between my devices and offer some kind of worst-case emergency backup.

Within the next weeks I’m going to start writing on my bachelor’s thesis and I’m 100% certain I’ll put all relevant files into my Dropbox folder because for me, there is no alternative which offers the same and adds extra value. With today’s annoucement Dropbox even offers competitive pricing in comparison to Google and Microsoft.

For me there is no reason to not use Dropbox or one of their spin-off products. I’m incredible happy with all of them!

I love taking photos, especially of places and buildings I’ve never seen before. The half-year in Amsterdam is going to be a perfect opportunity to take a lot of pictures. They can be found here:

Link

Brent Simmons:

Sinatra and Node are very similar. But as awesome as Node is, it has one giant drawback: you have to write in JavaScript.
…
Ruby has a whole lot in common with Objective-C. Both languages count Smalltalk as an ancestor: both are object-oriented and both use dynamic dispatch. I think you’d like it.

I love Ruby and Sinatra. It really feels a lot like Cocoa programming.

I used Sinatra for my first web projects and was perfectly happy with it. This was the time when every post on Hackernews was about Node.js, so I got the feeling that the whole Ruby/Sinatra community is in decline.

I tried Node.js for my next little projects, it worked but I wasn’t really happy with it. Everything felt overwhelming and out of control (just look at all the packages express.js requires). I needed some time to realize that you should use what you really want to use and not what is the new hipness today because this will change tomorrow.

I’m going to use Sinatra again, as long as there is no serverside Swift.

In the recent days, there was a fair amount of hatred towards Swift. It seems a lot developers shipped their iOS 8 updates and started using Swift to implement features or new Apps. That’s great, and I totally did the same but you have to adjust your expectations on how your experience will be.

In limited ways it’s possible to write Swift like Objective-C without the brackets. All the Foundation, Cocoa and Cocoa Touch Objects and APIs are available. But you’ll start to stumble after a few steps. Optionals will be a huge pain at first. Some language features aren’t really there or work entirely different. (KVO and Arrays for example). That’s the reason why you shouldn’t write Swift like you write Objective-C. I remember the problems I had when I started with Objective-C and iOS development, because it was just 3 years ago. I knew some Python and the basics of Java when I started. You can image how confused I was: Pointers everywhere, the responder chain, id,…, the list can go on forever. Now everyone is in a similar situation again. We can’t expect to be 100 percent productive from day one.

This is the perfect opportunity to rethink the way we used to write our code. We are now in the unique position on actively defining the future of the language we will use for coming years or decades. We can do it by filing bug reports and feature requests, actively discussing best practices with blogposts, in the developer forum or even on Twitter.

It feels like I can see a bit of the future when I look at this beautiful code by Matt Thompson for his AFNetworking-succesor Alamofire

enum Router: URLRequestConvertible {
    static let baseURLString = "http://example.com"
    static var OAuthToken: String?

    case CreateUser([String: AnyObject])
    case ReadUser(String)
    case UpdateUser(String, [String: AnyObject])
    case DestroyUser(String)

    var method: Alamofire.Method {
        switch self {
        case .CreateUser:
            return .POST
        case .ReadUser:
            return .GET
        case .UpdateUser:
            return .PUT
        case .DestroyUser:
            return .DELETE
        }
    }

    var path: String {
        switch self {
        case .CreateUser:
            return "/users"
        case .ReadUser(let username):
            return "/users/\(username)"
        case .UpdateUser(let username, _):
            return "/users/\(username)"
        case .DestroyUser(let username):
            return "/users/\(username)"
        }
    }

    // MARK: URLRequestConvertible

    var URLRequest: NSURLRequest {
        let URL = NSURL(string: Router.baseURLString)
        let mutableURLRequest = NSMutableURLRequest(URL: URL.URLByAppendingPathComponent(path))
        mutableURLRequest.HTTPMethod = method.toRaw()

        if let token = Router.OAuthToken {
            mutableURLRequest.setValue("Bearer \(token)", forHTTPHeaderField: "Authorization")
        }

        switch self {
        case .CreateUser(let parameters):
            return Alamofire.ParameterEncoding.JSON.encode(mutableURLRequest, parameters: parameters).0
        case .UpdateUser(_, let parameters):
            return Alamofire.ParameterEncoding.URL.encode(mutableURLRequest, parameters: parameters).0
        default:
            return mutableURLRequest
        }
    }
}

I’m incredibly excited about Swift and love writing code in it. It’s possible that it will be the only choice we have to develop native applications for Apple products, so why not start today?

Just a quick life sign. Yesterday we arrived in Amsterdam. This is will be my view for the next 6 month.

With today’s release of Ghost 0.5 it’s a perfect moment to talk about the software and services I’m using to run this site.

Content Management System

I’m using Ghost. Not because I’m incredibly keen on using Javascript with Node.js but I can’t see a better alternative. Ghost is lightweight in comparison to Wordpress, heavily uses Markdown and I can publish on the go thanks to it’s web interface. I’m not interested in writing and maintaining my own platform, so Ghost is ok for me. I’m also watching the development of Kirby, maybe I will switch in the future, we will see.

Theme

The theme is a fork of Sven Read’s awesome ReadiumTheme. It’s available on Github

Hosting

This site is hosted on Uberspace. Those guys offer an incredible service for a “pay-what-you-want” price point. All the administration is done via ssh and the command line. The nerd way of doing things. The support is really helpful and fast. I can’t recommend them enough.

– Update: This blog is now hosted on a Digital Ocean VPS - read more here

Domain

Hover. Seamless, fast, no bullshit. If you are using a different registrar, do yourself a favor and try Hover. I love them.

I love to read about apps, tools and products other people use in their day-to-day life. Especially The Setup and Justin William’s Tools list. So why not list the hardware and apps I am using? This post will be Mac-focused. I plan to write similar posts about iOS-Apps and my iOS-Development tool chain.

Hardware

• Macbook Air 13” mid 2013: This is the only computer I’m using. It has the i7 Intel chip, 8gb ram and a 128gb SSD. The hard drive is small but it’s totally ok to have the big image and iTunes libraries on a fast external USB 3 drive. The obvious downside of this machine is the display but let me tell you this: 11 hours of battery life are amazing!
• cheap Benq 24” monitor: nothing fancy here, just a place for huge Xcode Storyboards.
• iPhone 5: It is still a perfectly fine phone but I plan to upgrade to the iPhone 6 this winter.
• iPad Mini: I have no real use case for this device. It is mostly a Youtube-Player.

Development

• Xcode: Not much to say.
• Dash: I do not know if I would enjoy using Xcode without Dash. It’s a documentation viewer, incredible fast and supports all kinds of different languages and frameworks. I use it in combination with Alfred, which I’m going to mention later.
• Chocolat: All non iOS-Code (HTML,CSS, Javascript, Ruby and one day hopefully Haskell) is written in Chocolat. It’s a modern OS X app, active in development and has all the features I need.
• Github for Mac: A simple GUI for Git. Free and not bloated with features I will never use!
• Transmit: Best OS X FTP client!

Design

• Sketch: I’m using Sketch for all my interface designs, icons etc. It’s inexpensive and easy to get started.
• Spectrum: The native color picker feels useless in comparison to this app.
• Ember: A place for all my screenshots and inspirational images.
• Xscope: Who does not need a digital ruler with some extras?

Productivity

• Airmail: Mail.app is ridiculously broken with Google Mail and feels heavy and old. Sparrow is no longer in development, so Airmail is the best alternative I could find.
• Omnifocus: I plan all my more complex projects and tasks in Omnifocus.
• Wunderlist: All simple lists go in here. Version 3 is beautiful and the sync is unbelievable fast.
• Alfred: Spotlight on steroids.
• 1Password: I hope there is not much to explain here.
• Pinboard + Spillo: I’ve used Evernote for managing all my bookmarks and interesting bits I found on the web. This became an unmanageable mess because Evernote tries to combine too many different concepts, which does not work for me. Now I’m using Pinboard in combination with the Mac client Spillo. It’s simple, focused and easy to use.

Writing

• Day One: I’m using Day One to write down all my thoughts in Markdown, including these posts.
• Marked 2: Marked is a great Markdown previewer with all kinds of useful and unique features. If you write in Markdown, have a look at it.

Hi,

my name is Martin, I’m a computer science student and iOS developer from Germany. You can see my Apps here.

This is going to be the place where I write about Apple, tech, programming, life and everything else I’m interested in.

It is my first time trying to write something meaningful in English, so feel free to contact me about misspellings or grammatical flaws. All content of this site will be open sourced on Github. This includes the Ghost theme and all the posts. So the best way to point to errors is by pull request or issues.

I’m starting this site now because a lot is going to change for me in the next few weeks. My girlfriend and I are going to move to Amsterdam for half a year. I will finish my degree with an internship, so there is a lot to learn, experience and to write about.

Feel free to subscribe to the RSS-Feed or follow me on Twitter.