Category: Swift

iOSCon 2017

The 2 days came and gone, so fast you couldn’t believe, it all had ended so fast!
As last year, the organisation was excellent and everything went really well…

I enjoyed all the talks that I attended and had some difficult decisions to make, the two tracks made choices impossible sometimes.
So here are my considerations:

First day

Please don’t lose the master class from Dan Cutting, The Grand Tour of iOS Architectures. A really good explanation of all the MVC, MVP, VIPER, CLEAN and FLUX or REACTIVE architectures/patterns.

Another talk not to lose is TDD in Xcode Playgrounds by Paul Ardeleanu: The power of TDD in a playground showing you how to quickly get feedback from your tests, and how can you then move the tests to your project.

Swift on the server was well represented by this workshop: Workshop: Building a server-side Swift app with the Kitura web framework by Chris Bailey and Ian Partridge.

If you are looking for a new job, please don’t skip Ace The Technical Interview by Abizer Nasir. Very good advises there.

Second day

You get to venue with mixed fillings: you are super excited for the new talks ahead, but you are also exhausted from day before…you are starting to think that your brain can’t take much more, and you sit down to listening to the keynote by Daniel Steinberg, and you definitely start to rethink your life. Why? How? What?

Another great talk was Going Universal: Building an app for Mac, iPhone, iPad and Apple TV (and staying sane) by Adrian Thomas where he explains the process of building and app not just for the iPhone, focus on how to organize your code (essentially your shared code) but not forgetting the UI and how you should maintain some core elements between the different versions of your app.

Unfortunately, there is no video for this excellent workshop by Phil Nash: Test Driving Swift To The Max – with or without the tests!. Very enlightening and using AppCode instead of Xcode.
Building better iOS apps with GraphQL, doesn’t have a video too, but was a really nice talk about how to talk to the server without a REST API. Will it be the next hype on iOS?

And that’s it, folks! Next year there will be more.
It was really nice to reencounter friends and make some new ones and learn new things.
Never stop learning!

When a good architecture helps you in your UI design iterations

I’m currently working on an internal app for Codurance, which started as a pet project while I was working with my previous client. I started the project with one simple goal: to make it work. After six or seven months of trying to put it all together in my spare time, I ended up with a skeleton of a working app. However, I wasn’t entirely satisfied with my work. Even though I had been test-driving all the code and all my ViewControllers were as light as I could imagine, I thought it wasn’t enough. So I decided to carry out a big refactoring and apply the VIPER architectural pattern.

So what’s VIPER?

VIPER stands for View, Interactor, Presenter, Entity, and Router, and it’s a version of the clean architecture applied for iOS. It’s not my intention to take a deep-dive into VIPER in this article, but if you are interested in learning more, (here)[https://www.objc.io/issues/13-architecture/viper/], you have a good definition of the architecture, and here you can find a good explanation that can help you decide if you want to use it in your app or not. The section “Benefits of VIPER” in this article explain quite well why I decided to use VIPER.

Make it work

So as I explained, originally my main objective had been to make it work. And I did. With my big refactoring in place, I finished my goals for the app in no time, having the major features working. The app looked like this at that time:


This version had several problems: The way to add or delete new TimeEntries was completely obscure for a new user: you had to swipe the cell to see the buttons. I was using this pod: SWTableViewCell to achieve this. I was happy because my app was working, but I was sad because it wasn’t an app that I would like to show off. So I had a talk with our UI expert, and we decided to start iterating till we get the UI into a more satisfactory state.

First Iteration: Copy Google Calendar


Even though this app is not a calendar app, it all revolves around time entry. So we first looked at apps that had the objective of entering timed slots of work, but most of them were more like Excel sheets than apps. And because my initial idea was to have a list of TimeEntries, we looked at the Google Calendar App. The simplicity and clean design called to us, so we decided that could be a good first step to do a similar design and iterate from there. It looks better, doesn’t it? But there were still usability issues I wanted to address… I was insisting on having this swipe version because as a user, I prefer apps that have all at hand and I don’t have to go into several different views to achieve something. So I was kind of insisting on just having a one view app.

Second Iteration: Remove hidden functionality


So with this in mind, and playing a little with colors (I must confess that the colors here are my fault 😊 ), we added the functionality to the only view of our app. Giulia helped me to improve usability and the result wasn’t that hard to implement. She also decided to have 3 different views of the data since we have 3 types of user: the ones that update their hours daily, the ones that do it by week, and the ones that only do it once per month.

Third Iteration: Trying to have insertion in just one line


As you can see I’m very bad at choosing colors, but right then we were more worried about having everything that was related to a new insertion on just one line and about keeping it simple. The delete functionality stayed in the swipe, but that is an expected behavior from an iOS app, so we were ok with that.

Fourth iteration: Playing with colors


Finally, Giulia dedicated some time to me (I guess she was horrified with my colors choices 😜 ) and decide to have a look at the colors. Notice the difference? Me too…
But we were not yet happy with the insertion line. The field to search activities was too small and the stepper was too big in comparison.

Fifth Iteration: Add a picker view


The fact that now we have a PickerView gave us the space we needed to have a big text field. It all looks more harmonious and is still doing what I had in mind: just use one view to do everything in the app.

What VIPER had to do in all this

As you can see, I had to change the UI several times and some were radical changes (for example, we had a version where we tried to put the insertion line in the bottom, after the list). But because I had everything really independent and a good separation of concerns, I just needed to change my UI elements and wire them into my ViewController and there you go, everything else would work like a charm. The longest that it took me to make these changes was two days, partly because I had some problems with AutoLayout.

Conclusion

The decision to adopt the VIPER architecture was a good decision, and even though I don’t have a big set of new features coming up, I really appreciate the fact that I always know exactly where I have to go to find something in the app. We still have some functionality that we want to add to the app, but I think that the design is largely done. Another thing that I felt was that I didn’t want to “kill the designer” when Giulia appeared with new ideas that would make me change all of the design. It was really simple to adopt and painless. And that’s definitely a good thing to have.

Server Side Swift

In December 2015 Apple open-sourced Swift, which has been a real success. Many developers are contributing, not only via pull requests directly into the source code, but also by helping to define the shape of the language in the swift-evolution repository.
One of the things that came with Swift was server-side development. There’s a new version of Swift developed for Linux with a toolset that includes a package manager, the LLDB debugger, and the REPL. This opens a whole set of new possibilities for a lot of companies, such as IBM who are currently making a huge investment in its framework Kitura.

So why?

  • Compared to Python or Ruby – it is super fast and a type-safe language.
  • It is a language which allows developers to write expressive code.
  • As an iOS developer, you can stay in the same technology stack. If you need to develop a Web service for your iOS app to retrieve data, you can write that in the same language, using the same tooling…
  • Devs love Swift 🙂

So, what’s on the market?

There’s a lot of small frameworks that take advantage of these new possibilities, so have a look here where Edward Jiang does a great job of introducing four of the more promising frameworks already in the market. I’m divided between Vapor and Kitura:

  • The first one is growing in popularity and is starting to be the one to used in all tutorials that I’ve picked up:
    • It’s inspired by Laravel
    • Aims to be expressive and simple to use
    • Has great documentation
  • The second, Kitura, is from IBM, which reveals the extent of their belief in the advantages of this approach to application development. Alongside the core framework, IBM has also invested in:
    • A package manager, which allows developers to add their own packages
    • A sandbox environment, to allow developers to test Swift on the server-side
    • A Cloud server that is specialised for deploying Swift

Kitura is based on Express.js, so if you are already using it you will find almost no differences at project level structure and so on.

If you want to have a look of all the stack that IBM has, you can go here.

Can you convince me?

You are a backend developer and you thinking: “Nah… I’m not going to learn a new whole language…”
Well, don’t forget that Swift, first of all, is a type-safe language. And it’s a hybrid in that it supports Object-Oriented and Functional programming. A huge advantage of this is the ability to introduce yourself into functional programming, but still be “safe” in your object-oriented skills.
Yes, you would have to learn a new language… But it’s Swift!
Not convinced yet? Take a look at these 2 articles that compare server side Swift (in this case Vapor) with a lot of other well-known languages:

Please note that these tests were made before Swift 3.0 came out.

Conclusion

If you are a iOS developer, and you need to have a Web service for your app, you should definitely consider one of these options, since you won’t need to learn another language to deploy your Web service. If you are a backend developer, you can always learn a new, type-safe, language and then who knows? Maybe start creating your own iOS apps?