[Our ordr.interns and part time dev (who was an intern last summer) were just at the beginning of some projects and after Apple announced Swift, we were all reading the Swift book. It occurred to me that best way to learn is by doing - and so three days of madness ensued. And to be clear, by doing I mean them doing and me watching. --felix]

The future is here! You can now write code to order food directly from your iOS apps...in Swift! The Ordr.interns built an alpha Swift API wrapper and it is now available for everyone to use.

The story

As we began to settle in to our second week as interns, David and Felix suddenly called us aside for a mysterious meeting. They asked how we would feel about dropping everything we were working on to make a wrapper for the Ordr.in API in Swift, the new language that Apple released last week for iOS development. After a few minutes of discussion, we excitedly jumped right into getting started. It’s not every day that you get to dive into working on the bleeding edge of technology - last week at Ordr.in, we did exactly this. Building quickly was necessary in order to get a head start on being relevant in the rapidly growing community forming around the new language. With the buzz around Swift exploding, we had our work cut out for us if we wanted to finish this in time to keep up with the hype (especially with experienced iOS developers already implementing games like Flappy Bird in Swift). We had three days to build the wrapper to support the entire Ordr.in API, and we gladly worked hard to get shit done.

Our experiences with Swift

The three of us had absolutely no experience with iOS development prior to this project. We had to go through the hoops of learning a new language in a new environment (Xcode) with no resources other than the language specs and Google. We had three days to do this, so we plunged headfirst into hacking on the API wrapper figuring things out as we progressed. Little by little, the nuances of the language revealed themselves to us in the form of errors that we deduced how to fix. We picked up on subtleties such as arguments being immutable inside the body of a function. This is a clever move on the part of the language’s designers because changing the values of function parameters inside of a function could potentially cause unexpected side effects. The fact that parameters are immutable by default forces the developer to follow better practices.

We all come from a Python and JavaScript background, so it was great to see patterns that reminded us of these languages. Allowing function arguments to have default values like in Python was great, and we were also able to pass around callback functions like in JavaScript. Optional parameters are also allowed, which gives us the ability to write more generalized code for making API requests. With this comes the concept of “unwrapping” variables, which may cause some seemingly obscure compiler errors if you are not in the right mindset while getting used to Swift. We thought that it was an interesting choice to require names for all function arguments except for the first one, when calling a function. This was weirdly annoying for us at first as we were making a library that was not very iOS specific, but this pattern makes more sense in the domain of building iOS apps.

Hurdles we went through when getting started

Online resources like Stack Overflow were relatively barren because the language was literally one day old. The Swift docs that Apple provided were comprehensive, but did not really touch on anything specific to Xcode, Objective-C or iOS. Although these can be found elsewhere, we spent a lot of time wrestling with problems in this domain. Xcode would spontaneously debug our program even with no breakpoints. When we would make HTTP requests, the execution would hang and the message “lldb” would display, representing the debugger prompt. This was solved by configuring Xcode to not debug executables. We also found it extremely annoying that Xcode displays a clickable error symbol right on top of where breakpoints are set. It was frustratingly easy to accidentally set a breakpoint by misclicking next to an error prompt. Learning how to manipulate the Xcode environment effectively was actually harder than picking up the language itself. This speaks to both how easy it is to pick up Swift with prior coding experience as well as how clunky Xcode can be if you are unfamiliar with it.

We spent a while trying to figure out the best way to package our API for other developers. We’re aware of Cocoapods, the dependency manager for Objective C, but we were unsure of its compatibility with Swift. In the end, we decided to just include instructions on how to import our code manually. While Swift code can usually be dragged and dropped for ready use, our API requires an extra installation step because of the Objective C code that is mixed in. One note: import statements are not necessary for Swift code contained in the same target.

Setting the standards

Swift is a language that does not have any accepted standards or best practices yet. When trying to look for examples of what other people have done before, there was very little to find. We found very few open source projects to base ideas off of, although we did learn about how HTTP requests work in Swift via an open sourced framework we found called Agent , written only hours before we started working on the wrapper. The open source community around Swift is sure to grow immensely in the coming days or weeks, but there is still so much room for discussion. Given that our project is open sourced, we hope to help other prospective Swift developers who may not have many examples available to work off of. We are glad to be part of the earliest group of Swift programmers, and look forward to seeing where the language and its community will go in the near future!

Our impressions of Swift

Sam: I personally haven’t written code in a typed or compiled language in a while (too many fancy scripting languages #hipster). It was both enjoyable, yet slightly annoying, to get back into that mindset. Swift is obviously more fun to write than something like Java because of all the similarities it shares with my preferred languages, and because Apple really tried hard to make it more accessible/developer friendly. I liked that it was not super verbose (unless you compare it to Python), and that we could work quickly in it. Including variable types in function arguments promotes more self documenting code, which is something I highly value. I think most of its quirkiness came from the fact that we had no idea what we were doing at first, but I would say Swift does exactly what Apple intended it to do by lowering the barrier of entry for iOS dev. I can see myself hacking in Swift again if I ever want to make a quick iOS app.

Eric: After skimming through the Swift docs, I was intrigued by how different it was from my preferred languages (JS, Python, C). I was excited to try it out and play around with new features like optionals which I haven’t worked with before. Unfortunately, many of the problems we ran into during development were related to XCode and the way it sets up projects. The actual programming involved was fairly trivial and I wasn’t able to play around with the language as much as I’d liked. That said, Swift (not XCode), has left a good impression on me and I hope to use it more in the future!

Polina: It’s been a relatively long time since I jumped onto a previously unfamiliar to me language, so the challenge of diving head-first into unexplored syntax and rules was refreshing. The lack of explicit standards and examples, beyond the simple textbook samples that the docs gave, brought an extra level of enjoyment. Speaking of the documentation, it is rather complete and covers most questions one would have about Swift, which makes it possible to quickly jump into the coding. That being said, Swift has its hidden peculiarities (as mentioned above), although it’s fully possible that they were inherited from Objective C - the primary language of iOS development up to this point.