The game around apps has shifted. You should not expect the user to come to your app anymore. We now have to provide them with our features whenever and wherever they need it. Lucky us, we can use a lot of extensions to deeply integrate our features into iOS.
After this talk, you will understand the global architecture of iOS Extensions, the UX challenges, and the main technical challenges.
Swift offers a unique choice for creating scientific applications. Swift can be used to bridge creating readable and debuggable code, using clean scientific notation, with a backend of powerful high-performance libraries. Object, protocol and functional programming paradigms freely mix, and when combined with prudent operator overloading and unicode notation, one has a powerful system. Despite Swift’s youth, it is already up to the task of quality professional scientific programming. Jeff walks through several small examples.
Languages that have a rather low barrier to entry often struggle when it comes to performance because too much is abstracted from the programmer to make things simple. Therefore in those languages, the key to unlock performance is often to write some of the code in C, collaterally abandoning the safety of the higher-level language.
Swift on the other hand lets you unlock best of both worlds: performance and safety. Naturally not all Swift code is magically fast and just like everything else in programming performance requires constant learning.
Johannes discusses one aspect of what was learned during SwiftNIO development. He debunks one particular performance-related myth that has been in the Swift community ever since, namely that classes are faster to pass to functions than structs.
You write an app, you add a database to store the apps’s data. Seems simple enough. Over the years, though, the database scheme can quickly grow to become an untamed beast that makes you cry at night: adding extra columns that are really a cache of computed properties or extra tables to normalize some relationships needed in the UI. The database contains critical user data, yet can become the most hacked part of your code to correctly handle migrations and sync.
The problem is your database is used both for storing critical data and for displaying that data and managing the UI. Your data model is torn between two antagonistic goals, and you have a kitchen sink database. Charles proposes a different approach where you explicitly separate those two functions, and which was successfully applied to architect two apps I worked on.
Jan shares his experience with Marzipan and UIKit on macOS. He introduces the possibility of converting an iOS app to macOS and explains how UIKit on macOS works together with a bit of history and how they got to the current (alpha) state.
Are your apps “Pure Swift”? Don’t be so sure. Daniel demonstrates the extent to which Swift apps on iOS and Mac are dependent on legacy Objective-C conventions. He talks through scenarios where Swift facilitates interoperation, and how you can finesse the details. Stay tuned: he ends with a debugging trick that everybody will enjoy!
UITableViews and UITableViewCells are great. They are the bread and butter of iOS development. You can see them in pretty much every app out there. Knowing how to set them up is almost like a right of passage into being a real iOS developer. But, they can be pretty cumbersome to deal with using Apple’s out of-of-the-box components. Lea goes over a couple of examples on how to use Swift features like enums, protocols, extensions, and generics in practical ways to tackle everyday UITableView frustrations.
Swift Attributes - you use them in your day-to-day coding. The @decorations that @you put on your @code to more clearly express your intent for the code. Mark tours a number of attributes, and ends up by showing you how to search the compiler source code to find all of the attributes, providing a gateway to your own personal exploration of the compiler and the language.
Soroush discusses abstraction — what it is, and what it isn’t. He steps through the process of taking code that went from good to bad, and find ways to make it good again. How do we build an abstraction from code that isn’t abstract? What qualities are we looking for in our abstractions?