Take 3, Scene 4: Developing Apps for iOS9

In the fourth episode of Take 3, we’re joined in the studio by Sean Kosanovich and Matt Sich, two Software Engineers at 3Pillar, to discuss building and developing mobile apps on iOS9. iOS9 is the newest software update from Apple with new APIs and services to expand development abilities. The update also has a multitude of new kits to improve upon existing apps, and an app thinning feature that allows users to download apps specifically optimized for their device.

Episode Highlights

  • Sean and Matt expand upon the specific differences they’ve experienced when developing apps for iOS9 as compared to the other software iterations
  • The two of them compare developing with Objective C and developing with Swift, and expand upon the three concepts around which Swift was created
  • Both Sean and Matt talk about what they think iOS10 might bring, and what else might appear at Apple’s WWDC this summer

About the Guests

Sean Kosanovich is a Senior Software Engineer at 3Pillar with a background in full-stack development and a focus on native mobile applications.

Matt Sich is a Software Engineer at 3Pillar, where he works on a variety of projects for 3Pillar’s rapid response coding and rescue team, Team Atlas.

Read the Transcription

Below is a transcription of the podcast as a whole.

Julia Slattery: Starting off, we’ve seen the commercials for the new iPhones running on iOS 9 with 3D touch and the tagline: “The only thing different is everything.” So when it comes to developing apps for iOS 9, is everything different as well?

Matt Sich: Yeah, there is actually a lot more that’s changed than just the 3D touch, but I guess 3D touch is something that most users will see as the big thing. But as a developer, there is a lot of stuff behind the scenes that has changed.

Sean Kosanovich: Yeah for example, something other than 3D touch that the users will see most often will be the iPad multitasking. So in iOS 9 on iPads, users can actually slide over and run two apps side by side. Also, for video applications, they can do picture and picture where they can actually minimize the video while they are doing other stuff.

Matt Sich: So as a developer, because you’re multitasking on iPad, it’s making us start looking a lot more at the responsive layout as opposed to when in the earlier iOS’s, a lot of apps were built without really thinking about different screen sizes. I remember I used to build apps with just a picture for the background and I didm’t have to worry about it because even if you double the size of the screen, it’s still going to scale up and you don’t have to worry about it now. I was just playing with an app where I made the design look really fancy – it wasn’t all flat and stuff and there was a lot more detail to it. And thinking about how to make that responsive design was not easy. So it’s way easier to do simple, flat designs now, and that’s a big thing as a developer that you have to start looking at now.

Sean Kosanovich: Yeah and going away from user features, from a development standpoint, you have to look at Swift 2, which is the second version of the Swift programming language that Apple debuted in 2014. A lot of developers skipped out on Swift 1 because it was very immature and didn’t do a lot of stuff and developers were just getting up to speed on it. But with Swift 2, a lot of developers are picking it up now that it’s more mature. And as far as development, of course the entire language is new, so that’s huge.

Julia Slattery: Alright, so you kind of talked about this, but Apple switched the programming language that powers iPhone and iPad apps from Objective C to Swift last year. What was the reasoning behind that and what kind of impact have you seen in developing iOS apps?

Sean Kosanovich: Yeah, I think it’s important to note that even though Apple has this big initiative with Swift – and now it’s open source and all this fun stuff – Objective C is not going away any time soon, and you can actually use Objective C and Swift code in the same project, they work very well together.

Matt Sich: Last month, I was working on the app for our 3Pillar podcast, and at that time when I first started working on it, I hadn’t switched over to Swift yet, but the whole project was in Swift. I was working on the audio player component for the app and I built it in Objective C and we integrated that, and a week after I built that I switched over to Swift, and that was kind of like my first jump into Swift. But they work together seamlessly.

Sean Kosanovich: Now to get into why did Apple feel that this was a new time to create a new language: So Objective C has very archaic roots; it’s a superset of C++. Most developers consider it very ugly and very cumbersome because you’re dealing with pointers in raw memory locations. So Swift is kind of this modern language, and it was created around three concepts: safe, modern and powerful, and I think we can go over some of those aspects here.

Julia Slattery: Sure.

Sean Kosanovich: So looking at the safe concept of Swift, there’s a lot of features built into the language to really help developers to remove a whole section of the bugging errors that we see all the time when developing apps. For example, at the most fundamental piece is this concept of constants, and every language has this; Objective C, we have the const keyword, in Java, we have a final keyword. But there is one huge difference in the way Swift did this, and for collections like arrays and dictionaries and maps, when you define it as a constant – which is with the let keyword – that array is now immutable, whereas in Java, when you say final array, you can still add and remove stuff from it. This is a huge idea, because now when you’re writing your code, you know exactly what’s going on; can this array change from somewhere else, maybe another thread in the code or so forth.

Matt Sich: I think from working with Swift in the past month, I’ve realized that that’s a factor in getting everything organized. And really like you said, it’s a big way to make sure you don’t make the mistakes that you would probably make with Objective C and not really see them until it broke something.

Sean Kosanovich: Yeah absolutely. And moving ahead, I was actually lucky enough to be at WWDC for the past two years, so the year that Swift was announced and last year when Swift 2 came out. And one of the biggest contentious areas is this fundamental change around optionals. The idea is you will never essentially get a null reference at run time anymore. And a lot of developers don’t like it because they think it makes their syntax real messy, because they see a lot of these question marks and exclamation points all over their code. However, if you are using optionals correctly – I think the most common way an app crashes is when you’re trying to use an object that has no backing store to it. But when you’re using optionals correctly, you completely eliminate that; it’s all checked by the compiler.

Matt Sich: Right and just by using optionals, I found that whenever I’m writing any kind of Swift and then running it, I haven’t had any crashes because I have optionals. The only crashes I think I had were on button ad targets because my target was missing; those are the only crashes I’ve had really during an actual runtime. So that definitely, definitely helps a lot with that.

Sean Kosanovich: Quick little story: I believe it was two years ago, there was this huge security flaw in Mac OS X regarding SSL certificate validations. And it turned out that the bug was caused by an if statement that didn’t have brackets around it. So when you’re doing programming, if you only have a one line, typically underneath an if statement, you don’t require brackets to group code together. In this case, they had multiple lines and forgot the brackets. Apple learned from that mistake, and now Swift requires brackets for all its statements no matter what. It is actually compile time error if you are missing them, and that would completely solve a lot of these very easy to miss mistakes as a developer.

So we talked a lot about how Swift is safe, but moving on to one of the second core principles of Swift would be modern. Swift is a very modern language. When you think of a lot of these newer languages, Groovy or Scala or even some of the newer JavaScript features, there are a lot of real nice features in these languages that Objective C just didn’t have. For example, type-in is a very powerful compiler option that happens in Swift. Essentially, when you’re defining your variables, if it’s a string or a number or an object, you don’t have to say that this is a string; the compiler figures it out automatically and it saves you from actually having to type which type of variable you have, whether that’s a string or a number.

Don’t get this confused with JavaScript; in JavaScript, when you are creating variables, you use this var keyword. And JavaScript is very dynamic – you could have a string and then assign a number to it and then maybe assign it back to a different object. Swift is actually type safe, – and again, this kind of goes back to that safe concept that we heard earlier – it’s a statically typed language. You can’t take a string and assign it to a number, even though you have the benefit of not having to declare the type.

Matt Sich: I think ES6 in JavaScript definitely has got it to the point where it really reminds you a lot of Swift. And I think that’s a big part of Swift being modern, is now as a web developer, there’s a big push to move the whole main stack to JavaScript. So jumping on Swift is pretty easy for someone that’s coming from that because it really looks similar. But also, Swift has something called tuples which is really cool. If you have a function and you want to return multiple items, in Objective C what I usually would do is return it in a dictionary, an array; but in Swift I can just return a tuple, which means that my return type can be in parentheses and it would be name, string and age int. Then if I call that function, I can have that function.name and I could get the name that was fetched back from it. So it really helps move things forward faster while you’re working. Also, Swift uses closures as a return block; like in Objective C, you had blocks. For example, if you want to do a UI animation, there is this method called UI view animate with duration and there’s a block in there where you could see what the animation is. In Swift, you use closures and it’s the same idea.

Sean Kosanovich: Moving along with closures, essentially it’s a chunk of code that you can assign to a variable that could be run at any point. For those of you that might be familiar with Java 8, Java 8 has a similar feature called Lambdas. But Swift takes this a lot farther – so in Java 8, you actually have to have interface backing your Lambdas, whereas in Swift, you could just write an arbitrary code, assign it to a variable, and run it in any context, which is really awesome.

Matt Sich: Swift is also powerful because the string interpolation allows you to have a forward slash in parentheses variable name inside your string to directly place the variable inside the string wherever you want. You also have ranges where, for example, if I have an array, I can just put in the index of the array to access the array object at that index, but I could also give it a range. So I can do array 1…5 and it will give me all the objects in that range of the array.

Sean Kosanovich: Some other very powerful features of Swift would go to the switch statement. I know a lot of people probably think of switch statement, “oh that’s so old school,” but Apple actually paid a lot of attention to it in Swift. For example, you can do pretty advanced pattern matching inside of Swift statements now. Imagine you’re writing a program that graphs some coordinates, X-Y Coordinate System, and you could switch on x, y and you could say a case where x is bigger than 0, do this. Maybe you have different routines you do depending on which quadrant you’re in in your graph. So that’s very cool to be able to do this powerful pattern matching that you just simply cannot do in other languages. It’s really cool.

Another really awesome feature is this idea of computed properties. So typically when you define a class or a struct, you create your variables and they are there all the time. But what happens if you want something dynamic? In other languages, you would typically write a method, get name, and you would do some calculation to get it. But that’s not very elegant when you’re looking at the code and you see all these function calls. In Swift, you could actually have a computed property, so you access it with the dot syntax. So you could say person.name, and that name might actually carry out to a function that does some calculation to return the value.

Julia Slattery: Alright, so looking at apps that already exist, are there areas or opportunities that iOS9 opens up that those app owners should be looking at if they have a mind to update their apps?

Sean Kosanovich: That’s a good question. We can’t go over all the features that developers can bake into their apps, but we’ll highlight a couple of them real quick. One of the really cool features that Apple introduced last year at WWDC, in iOS 8, is a Cloud Kit. It’s essentially a way for small app developers to have cloud access – they don’t need to have a hosted cloud, they don’t have to pay Amazon web services to host their own server logic, they could use Apple’s free of charge. There was one huge drawback with that at the time because it only worked on iOS. So me as a developer, if I wanted to support Android or even a web version, I simply could not do that. So new in iOS9, Apple actually created a JavaScript framework around the Cloud Kit API, which enables developers to do pretty much everything they want. If you need to provide an Android or web implementation, you can do that, and Cloud Kit will ensure that all of the data is synced across all of your devices, your Macs, iOS devices, web, Android, or whatever. The sky is the limit at this point with the new Cloud Kit API. So I think apps that leverage Cloud Kit are going to see a huge boost in usefulness for the end users.

Matt Sich: Also, a lot of people with 16GB iPhones know the hassle of worrying about the memory allocation on their phone. With iOS9, there’s actually this thing called App Cleaning, which, when developers build their app and upload it to the store, allows Apple to send the user a version of the app that only has the resources it requires. So as a developer, when we create these apps, we provide image resources that have a high resolution. We’ll probably upload an image that’s at 2x or ultra high resolution that’s at 3x and for some older phones that have low resolution screens, they don’t need those at 3x or maybe even at 2x depending on the phone. That can take a lot of space, and it’s a waste of space if you’re downloading those resources and you’re never using them.

Also, there’s on-demand resources that will be downloadable after the app has been downloaded. For example, if you have a game app with multiple levels, when you first download it, you’ll probably only have the first level downloaded; as you play it, however, it will download those extra levels on demand. This makes the initial size of the app much lower,w hich is good for a lot of developers because if you’re downloading an app over your cell network, you can’t download an app that’s over 50MB. Now that developers have this, they can decrease the size of their apps so that people can download it over their cell networks.

Julia Slattery: So we can’t talk about iOS9 without talking about iOS10, which will reportedly be unveiled this summer at Apple’s WWDC. Is there anything big you’re expecting to see in iOS10 when it’s released?

Sean Kosanovich: One of my hopes – and this isn’t necessarily an iOS10 feature – but this past fall when Apple released the Photos app for iOS10, it was found out that they were using a hidden UI framework called UX Kit. UX Kit is this translation layer for the Mac that actually mimics the iOS UI Kit and it would enable developers to create one application that runs on every single Apple device out there and on one code base. It would simplify development significantly. No one knows for sure if UX kit will get released, only Apple knows that, but I’m very hopeful that Apple will go forward and make this a public resource for developers.

Matt Sich: I think iOS10 might also have some more help for developers when it comes to the auto layout stuff, because it’s becoming such a big part of iOS apps right now. They might have some big improvements in that area.

Julia Slattery

Julia Slattery

Marketing Content Specialist

Julia Slattery is a Marketing Content Specialist for 3Pillar Global in our Fairfax office. She manages content for 3Pillar’s web properties, hosts 3Pillar’s ‘Take 3’ podcast, and assists with the production and editing of a wide variety of audio, video, and written content. She holds a BA in Writing, Rhetoric, and Technical Communication from James Madison University.

Leave a Reply

Related Posts

How to Manage the “Need for Speed” Without Sacri... The pace of innovation today is faster than it has ever been. Customers are much more active and vocal thanks to social and mobile channels, and the c...
Determining the First Release The first thing you release needs to put the solution to your customer's most important problem in their hands. Deciding what the most important probl...
The Art of Building Rapid (and Valuable) Proofs of Concept Clients and stakeholders want results. They want assurances that their investment is well spent and they're building the right product. The software d...
Are You Doing Stuff or Creating Value? You can put a bunch of stickies on the wall, create tons of JIRA tickets, and commit lots of code, but are you creating value? Is the work your produc...
Costovation – Giving Your Customers Exactly What They ... On this episode of The Innovation Engine podcast, we delve into “cost-ovation,” or innovation that gives your customers exactly what they want – and n...