Swift Alps – as the name might imply – is a conference revolving around anything Swift related. As the name might also imply, the conference takes place in the Swiss Alps, in Crans-Montana more specifically.
What sets this conference apart from many of the other conferences out there is the format.
Instead of the “traditional” presenter/audience format, Swift Alps is centered around workshops where a mentor runs the workshop and a limited number of participants will pair up and work together learning new material. Each workshop takes 2 hours and you can attend a max number of 3 workshops each day.
This year the topics range from Accessibility to ARKit and reverse engineering to name a few.
2018 is the third year the conference takes place and first year with attendance from Nodes.
After waking up to this
It was time to head to the conference to get registered.
After registration, caffeine level adjustments, getting access to the wifi and a brief introduction of their workshop from each of the mentors, it was time to get the show rolling.
The workshops lined up for Thursday was:
- New generation networking with Swift-NIO by Florent Pillet
- Level Up Your Debugging Skills by Carola Nitz
- An “Intents” Guide to Custom Siri Shortcuts by Alexsander Akers
- Reverse Engineering by Guilherme Rambo
and the sad news was that you could only pick three out of these four interesting topics.
New generation networking with Swift-NIO
The goal was to continue the work started by Florent on either an iOS chat client using Network.framework, or a macOS chat server using Swift NIO, and my session buddy and I chose to start out with the client app.
In my normal, day to day work, networking work is something you set up at the start of a project – typically by copying some code you were satisfied with in a previous project, and then its just there, calling services, translating the returned JSON into model objects that you can use for your “real” work.
Therefore it was really fun and challenging to try and wrap your head around implementing a chat client from scratch. Starting out with making a connection (deciding whether to use TCP or UDP), actually connecting and watch the connection go through different stages before – hopefully – being established, and finally being able to send data over the network.
Apples new Network.framework was pleasant to work with, it felt very swifty with various handler closures and enums with associated values.
An interesting feature in Network.framework is the NWPath and NWPathMonitor which you can use to monitor the connection and react if it changes…or completely goes away. Super interesting when writing a network monitor for instance.
All in all a very good workshop, good work Florent
An “Intents” Guide to Custom Siri Shortcuts
Siri shortcuts were one of the bigger announcements to come out of WWDC 2018. There’s a lot of talk about powerful workflows you can add to your app to make your user experience better for both casual and power users alike. In Aleksander’s workshop, we learned about how Siri shortcuts work, or specifically how the Intents framework works, and then implemented them in existing apps we had. We soon found out two important facts about developing Siri shortcuts.
- Creating a new shortcut is super simple. All you need to do is create a new intent shortcut, provide it some info about what data it is expecting, what it should listen for, and what kind of action it is (voice call, ordering food, playing music, etc). Build it and run and you should be able to get to communicate with your app right away.
Structuring your app to perform useful tasks with the data input from Siri is a huge complex problem. Since the intent is in its own extension, it does not have access to the rest of your codebase in the traditional sense. You need to modularize your code in a way that splits logic into separate services, which can then be imported into the intent extension. If your app isn’t already set up like this, it can be a huge refactor effort.
We spent maybe 20 minutes setting up the intent and getting Siri to interact with our app. The next hour or so was spent refactoring the existing app so that the right code could be accessed by the Siri intent. All in all, it was a great exercise and shed light on what to expect when developing a Siri shortcut.
Level Up Your Debugging Skills
I admit it, I like to debug, I actually do! It gives me a good idea about the flow of a program, I can see values of variables in a loop for instance and it is a great tool in my daily work.
And since we’re doing confessions now, I’ll also admit that my debugging work in Xcode normally resolves to:
- place a breakpoint
and that is about it. Sure, I had my mind blown by the Advanced Debugging
video from WWDC 2018 and that also led to one conditional breakpoint in the days after, but that was about it.
So clearly there was potential for levelling up my debugging skills!
Carola had made kind of a treasure hunt which introduced us to various features in lldb directly from the terminal. We learned to have the debugger wait for a process to be launched, how to set a breakpoint directly in the terminal, how to use the repl to execute new code while your “real” code was paused and the final trick, how to update the UI of your app with help from the debugger.
By now lldb veterans may be rolling their eyes over this idiot discovering blatantly obvious things, but it was really interesting for me to be “forced” into using those features. Now I just need to keep integrating the more advanced lldb features into my daily workflow.
Thank you to Carola for a very fine workshop.
Final course on the menu Thursday was a real treat. An introduction to fooling around with the private frameworks in the iOS simulator. The mentor was no other than Guilherme Rambo, amongst many other things writer, at 9to5mac who describes him as
a Mac and iOS developer based in Brazil. Known for discovering Apple’s secrets and analyzing leaks
By using the tool class-dump we were able to find interesting ViewControllers in Apple’s private frameworks and then try to instantiate them from our own apps.
The interesting thing was, that for this to really succeed, we had to use good old Objective C, since this language – beeing more dynamic in its nature – allows you to more easily load private frameworks dynamically instead of using the linker.
Writing Objective C again was kind of depressing, not because of the language (I really liked Objective C back then), but because you became aware of how rusty you were in that language. Four years ago I was writing Objective C like there was no tomorrow, and now I was fighting the compiler over missing semicolons…how the times have changed.
We managed to get an example project running that could load the PencilView you normally use in Apples Notes app, it wasn’t pretty but really fun.
Later on, I managed to get an example working with the FUFlightViewController, and was then able to track our flight back home via Paris.
This session was great fun and it was interesting to see how you are able to get access to some of the secret frameworks that lies hidden in your simulator.
The schedule for Friday looked as follows:
- Swift Design Patterns by Paul Hudson
- Better Developer Tooling by writing your own Mac Apps with Cocoa Bindings by Benedikt Terhechte
- Accessibility on iOS by Monika Mścichowska
- ARKit – from basics to advance by Kateryna Gridina
Again, hard choices were to be made!
First on the agenda for me was an introduction to ARKit. We’ve already used ARKit on projects in Nodes so this was a really interesting topic for me to look into.
Kate helped us through a list of examples, starting with plane detection, loading a SpriteKit with simple elements scene from a .sks file, composing your own SpriteKit scene of objets and finally adding a “real” 3D model to a SpriteKit scene and have it render properly.
ARKit is still a relatively young framework and to me it still has elements of black magic attached to it, so it was nice to have the time and a mentor to help understand what actually goes on when ARKit starts tracking the world through your camera.
Design Patterns, we all know and love them right?
They give us developers a shared vocabulary. And at the same time it allows us to compose sentences containing seemingly normal words which – when spoken – makes absolutely no sense to non-developers
“Yeah well, I think I would go for dependency injection here, but if you wanna do a singleton then sure!”
Paul Hudson’s workshop was a series of design patterns examples, which could be applied to an existing app. The patterns was ranged in increasing complexity ranging from MVC to Coordinators (as famed by Soroush Khanlou) and you could mix and match as you saw fit.
It was – yet another -interesting workshop and few things beats the joy of trying to wrap your head around a design pattern, applying it to your code base and afterwards be able to delete line after line of no longer needed code.
When most people think of accessibility in app development, they think of.. well they usually don’t think about it. To be honest, most of the apps we develop at Nodes have very little effort put into making them accessible for users with disabilities. This workshop was really refreshing and showed another world of user experience.
We began by putting our phones in voice-over mode. This is a feature for sight-impaired users, which reads aloud the various elements on screen. You need to use a lot of obscure gestures to navigate between UI elements and discover actions. Even having your phone in this mode for 5 minutes is enough to make you realize that making this experience nice is a huge benefit.
We then took over a small sample app that was just a list of recipes, where tapping on one would open a detail view. We found that using this app with voice-over enabled was pretty cumbersome, so we applied some nice accessibility features such as element grouping, custom actions, and better accessibility labels.
Apple has been making a huge push for better accessibility lately and I believe accessibility will become a huge focus for app development in the near term future.
Many of us are iOS developers, which also means that we use (and love) a Mac for our daily work every day.
But how many of us has actually tried writing a macOS app?
Benedikt has, and he was here to tell us about the joy of using bindings.
Bindings – in broad strokes – enables you to very quickly wire up your model and UI code, thereby reducing the amount of code you have to write to update your model object when ever a user taps a button or the other way around: update your UI when the model updates.
They are an old technology (in development terms at least), powerful but also hard to debug, which is why you maybe shouldn’t rely on them too heavily when writing production apps.
But for internal “tooling” apps, bindings is perfect and allows you to ship internal tooling apps quite fast.
We were working our way through a series of examples and was able to make several apps with a lot of functionality and relatively few lines of code.
Bindings are interesting in several ways. You can do a lot with few lines of code, but make one typo and you are left looking at “interesting” error messages, in some cases you don’t even have to make the errors yourself, Interface Builder contains errors that you need to know your way around. At the same time you get a sense that this framework has been around for quite some time. The amount of options and possibilities are staggering, but sometimes well hidden and sparsely documented. An elegant weapon…for a more civilized age if you will.
I think many of us left that workshop with a sudden urge to start writing macOS apps instead of the “normal” shell script for internal tool projects, so…mission accomplished Benedikt!
So there you have it! Two interesting days flew by way too quick and now we’re back in a rainy and dark Denmark armed with a ton of new tricks up our sleeves.
It was an absolute joy meeting likeminded developers who loves the iOS platform as much as we do and learn how they attack the challenges we all face from time to time.
The concept of working together with a complete stranger on each workshop is really great, it means that you get to “know” a lot of the other conference goers really quick and makes it easier to talk over coffee afterwards.
So, big question, should you go to Swift Alps next year?
As we hope the above post might illustrate, we highly recommend it, both for the high quality content and for the social networking involved.
Swift Alps organizers, mentors and participants, thank you so much for two great days, we hope to see you next year.