Fabric
Stanfy
Contentful
Kanji Circle & Russian Q&A
Jobandtalent
CapitalOne
CocoaPods
Ustream
Karumi
SoundCloud & CraftKollective
Buddybuild
SoundCloud & GitDo
Badoo
Telefonica Innovation
Sketch
SoundCloud & AutoreleasePool Conf
Niji
Nozbe
Indie
PoWWaU
Spotify
SoundCloud
NSSpain & Masscomm
NSSpain & Wallapop
Learn about some techniques put into practice to build the Fabric mobile app using Swift to optimize the code for stability and maintainability, such as heavy reliance on compile-time safety through dependency injection, code generation, MVVM...
Building thin transparent security layers system , that does not fail when application keys are exposed; when servers are hacked; security that lasts as long as unique user's crypto keys (or passwords) are safe.
Mobile's role is both very dangerous and very important in system security. We will talk about how mobiles change traditional security layouts and dictate client-server relationships. How to protect the most precious and sacred thing -- the user's data. This talk is next step for you if you've already heard about security for mobile apps: it's not just about 'securing data', but about modern techniques and consistent security models. We'll talk a bit about end-to-end cryptography, user data based key management, trust/defence echelonization, zero-knowledge authentication. We will learn about thin transparent security layers system and its applicability in client-server systems.
With the dawn of Xcode 8, we are losing the ability to write third-party plugins. In this talk, we will take a look at the new Xcode Extensions APIs and Xcode's vastly improved AppleScript support to see how we can leverage those for customising Xcode.
- Quick introduction of Xcode terminology, so that everyone is on the same page regarding naming of the various pieces of Xcode and how they relate to each other.
- Overview of the Extensions APIs — right now, in the first beta, there are only extensions for the Source Code Editor, but there will probably a few more when NSSpain actually happens :) We will cover the basics of all of them in this section.
- Overview of Xcode's AppleScript support — we are going to use Scripting Bridge or AppleEventBridge in order to do the scripting in a language the audience is more familiar with, like Swift.
- Live Coding of an Xcode Extension — this section will cover a full example of how to build an extension, how to use the AppleScript support on the application side to implement more advanced features which aren't possible inside the extension itself yet and how the project would be build and distributed.
- A Quick Look at some already available open source Xcode 8 extensions which might be useful for people in the audience who aren't interested in building their own extensions, yet, or to get inspiration from.
In this talk, we'll explore how to harness Swift's features to create more effective, engaging, and comprehensive language apps.
Swift offers developers the opportunity to build more dynamic language learning experiences, yet most settle on merely displaying content. In this talk, you'll learn how to use animations to give more precise pronunciation and listening feedback, tweak Table & Collection Views to design more culturally-specific and immersive experiences, and manipulate Text Kit to create more engaging and purposeful reading exercises. We'll start at the high-level, by exploring underutilized teaching methods, and then get down to specifics, using examples from my projects. By the end of this talk, you'll understand which teaching techniques to use and why, and be equipped to create apps that are more than mere supplements to traditional classroom learning.
Software complexity is a real problem that is causing lots of monetary losses in enterprise software systems around the world. As iOS apps are getting bigger, they may start to suffer the effects of complexity (more bugs, ineffective testing...). In this talk we are going to explore how using more restrictive models than object oriented programming can help us manage this complexity, with the trade offs of producing less natural solutions, and an impact on modularity. The main topics will be:
- The importance of understanding our programs
- Kinds of complexity in iOS apps
- Effects of state in our understanding of programs, and in testing
- How Swift help us model a functional core
- Testing our functional core using property based testing
- Redux implementations in iOS
Despite appreciation for testing, iOS functional testing is still gaining acceptance. Where to begin when you have no UI coverage? How to differentiate between UI frameworks & pick one for your app? How to take advantage of testing announcements from Apple?
In this talk, you'll hear about how to properly appraise and choose which testing framework works best for your application, what are some best practices and what to avoid, and how to take advantages from testing updates from this year's WWDC. Other things I'll cover:
- Advantages & disadvantages of popular functional testing frameworks
- How UI tests improves the mobile QA experience
- How new changes in the Xcode Server (announced at WWDC 2016) makes continuous integration easier
On May 10, 2016 I released CocoaPods 1.0. After five years it was the start of a new adventure, but that release marks a milestone for our community. This is the story of CocoaPods 1.0—of triumphs, setbacks, and many late nights on GitHub. It's our story.
I've been the lead developer of CocoaPods for over a year, including the time in which CocoaPods 1.0 was under development. I've been on the core team for over two years, and in the course of that time I've interacted with hundreds, maybe thousands of members of the wider Cocoa community. I think it's worth taking a look back on how our community has involved through this particular lens, and also diving into what it means to have a "1.0" release of software that is so widely depended upon. When did we feel 1.0 was ready? Why wasn't it released earlier? What will change now that CocoaPods is 1.0? These are questions I've been asked countless times over the past six months, and I'm excited to shared the answers to them at NSSpain. (And yes, I can promise many inside stories that have never been told before!)
Styling apps with stylesheets is fast, it enforces focus on reusability, and it's literally a common language with designers. Although there are several interesting ways to consider, let's see if Swift can revolutionize this approach! 🐥
When working on different apps of the same brand, there are a lot of logic we build to be shared. It's also quite usual that apps wear similar design, that's when reusing style becomes pretty important. We came across several solutions when working with Objective-C, like Classy and NUI, and love both. I'd like to share the experience we gathered through building apps with them, the good parts and the tradeoffs, and how does it look like if we forget these and try to solve the problem with Swift and its awesomeness.
While there is plenty of literature about app architecture, navigation is often misrepresented. By thinking a good strategy to present new screens from your app you will be able to write better UI tests having all your dependencies under control.
In this talk we will introduce a new actor in our interpretation of a clean architecture called the Navigator, which is responsible of holding the navigation state. Sometimes the app navigation is very easy and there is no need for something like this, but if you app is fairly complex (let's say a TabBar with a NavigationController hanging from each tab, modal ViewControllers, etc) this can rapidly become one of the culprits of bad smells like code repetition or ViewControllers knowing too much about the environment. By using different Design Patterns like the ServiceLocator to build our dependency injection system we will be able to pass the right instances of our use cases and navigators to our presenters so we can replace their implementations when testing our UI code. This also allows us to build simple ViewController tests where we just test the interaction in one of them or test complex navigation flows in a very simple way. We have built several fairly big applications using this approach and we are very happy with the results. Can't wait to share it with the community :)
Brewbot has taken the principles of MVVM and coated them with some nice RxSwift & further separated «responsibilities» with DataControllers to get a nicely decoupled architecture when building our iOS application.
Breakdown of the talk:
- Small overview of what's MVC
- MVVM: What is MVVM and how it «improves» upon MVC
- The problem that MVC and MVVM shared; not «expressing» or telling where exactly should certain layers should go
- What are DataControllers and how Brewbot takes advantage of them to better separate concerns
- Taking advantage of RxSwift to «glue» everything together: learning how to detect proper scenarios where Reactive programming is a good fit
- Quick overview of how Dependency Injection could be applied to easily test the ViewModels and DataControllers
Building fantastic iOS apps requires a developer to do many chores that aren't directly related to building their specific app - things like checking tests are run on every pull request, keeping provisioning profiles up to date, managing test releases, and submitting builds to the app store.
Buddybuild makes it simple to automate these tasks, so iOS developers can focus on building their apps.
In this workshop, Chris will walk through using buddybuild to build an iOS app, add tests, set up code signing, send builds to test groups, collect testers' feedback and crash reports, and ultimately submit the app to the App Store.
We’ve poured over thousands of apps that flow through buddybuild everyday to gather data on the way real development teams build their iOS apps.
Do teams prefer GitHub or Bitbucket? How are teams using pull requests? How common is automated testing? How many developers does it take to build an app? Do iOS developers prefer red wine or white wine?
Learn how your fellow iOS developers build their apps, and improve how you build yours.
Chris Stott Co-founder / Engineer, Buddybuild
Chris built his first mobile app before the iPhone was ever released, and built his first iOS app after a bet in a bar.
Always up for a varied challenge, Chris has built many kinds of software : Xbox & Playstation video games, web browsers, taxi dispatch apps, home security, banking apps, and mobile audio recording studios, working at startups, huge corps and freelancing.
Chris co-founded buddybuild to make life easiest for other iOS and Android app developers and help them focus on building their own apps - rather than building and maintaining a build system.
Building reusable and well structured code is an aim of every developer. However that hasn’t always been easy in the Appleland. Recent changes and discoveries in some of the notsowelldocumented corners of XCode now made development using Frameworks a reality.
We would like to share our experience with building framework oriented apps, walk you through the architectural patterns and then seal this off by creating a project.
The exciting journey of changing your project architecture basing it on Frameworks and allowing developers to start using Swift in the SoundCloud main app.
Since the launch of Swift in 2014 we had used Swift only in the SoundCloud watch app. The need of having reusable business logic among other reasons led to a new architecture for the project based on dynamic frameworks where Swift would be a first citizen member. In this talk we'll explain the approach we followed at SoundCloud to change our app architecture allowing developers to start using Swift in the project. Learnings, caveats, and how the project and the company has benefit from this journey.
In this talk we'll consider principles of designing easy-to-test interfaces that help to build quality tests including discussions of different dependency management techniques both in Swift and Objective-C.
For product companies like Badoo, high quality products are important. New code is being produced and shipped fast with new features continuously delivered to users. One way of verifying a feature's quality is covering related code with unit tests. We'll talk about principles that help developers design easy-to-test interfaces and improve the tests quality both in Swift and Objective-C with real examples from Badoo app.
A collection of best practices for both designers and developers, to translate a visual design into reusable Swift UI components.
This talk will revolve around how to improve the collaboration between designers and developers, and for that I have invited a designer to give the talk together with me: Alberto Calvo (@pumpkin) from Bohemian Coding, the makers of Sketch. Based on our experience of creating an app together (hush, hush, still a secret) for the past year, we will present a series of best practices for both designers and developers, to translate a design into reusable UI components. Some of the topics will be:
- Creating reusable components in Sketch
- Modelling colors, text styles, etc. in Swift
- Leveraging Core Graphics for more complex stuff
- Creating UI components in Swift
A collection of best practices for both designers and developers, to translate a visual design into reusable Swift UI components.
This talk will revolve around how to improve the collaboration between designers and developers, and for that I have invited a designer to give the talk together with me: Alberto Calvo (@pumpkin) from Bohemian Coding, the makers of Sketch. Based on our experience of creating an app together (hush, hush, still a secret) for the past year, we will present a series of best practices for both designers and developers, to translate a design into reusable UI components. Some of the topics will be:
- Creating reusable components in Sketch
- Modelling colors, text styles, etc. in Swift
- Leveraging Core Graphics for more complex stuff
- Creating UI components in Swift
At SoundCloud we strive to keep our users’ iOS listening experience state-of-the-art. My talk will explain how mobile music streaming works over HTTP, our in-house playback library Skippy vs Apple’s AVPlayer, and what’s next for this top priority feature.
- Overview of HTTP streaming technologies (assuming no prior knowledge), AVPlayer, and Skippy (which is based off of the GStreamer open source multimedia framework).
- How we came to a decision to move away from Apple’s AVPlayer, and the challenges that come with parting ways a key Apple offering.
- Our rollout process for gradually replacing the playback experience from AVPlayer to Skippy player.
- How we measure and monitor performance of the Skippy player vs. AVPlayer. The decisions we make at SoundCloud are very data driven.
- What is coming next in the future for playback in the SoundCloud iOS app - video was just introduced in May with the launch of video ads in the US, UK, Ireland, and France. This will be scaling further very rapidly over the next year.
- Additionally, Apple made some advancements with their HTTP live streaming libraries (HLS). These were announced at WWDC 2016 for iOS10, so we will try to make the most out of the built in improvements in iOS 10.
Embark in a journey with some Sci-Fi characters to discover how the Mixins & Traits pattern can help you better design your classes, avoid multiple-inheritance problems, and propose a protocol-oriented, Crusty-approved™ alternative to composition!
In this talk you'll discover what Mixins & Traits are, and how they can help avoid the problems otherwise brought by inheritance and be an interesting alternative to composition, by leveraging the Protocol-Oriented features of Swift.
We'll start by demonstrating the limitations of inheritance (and even composition) in some concrete examples, then present the concept of Mixins & Traits.
With the help of some fun examples and a bunch of Sci-Fi characters, we'll then see how this Mixins & Traits pattern can solve those problems, make your architecture more flexible, protocol-oriented… and allowing to factorize your code in a new way.
We'll finish the talk with a very concrete use case of Mixins that will allow you to get rid of String-based APIs and make your code type-safe.
Let me show you how to design truly expressive, safe, and easy-to-use APIs by taking advantage of Swift’s features and powerful type system guarantees.
A case study: let’s take an existing ObjC-style API from Apple’s frameworks — NSUserDefaults — and let’s make it truly Swifty. To me, a great "Swifty" API has two features in particular: it’s expressive, easy-to-use, and nice — it gets rid of unnecessary boilerplate, it’s concise, it’s clear; and it’s also safe — it takes advantage of static typing and compile-time guarantees to ensure that many kinds of bugs are simply impossible to make. The talk is also a story of my journey with static typing — coming from Ruby background, I used to think that static typing is unnecessary and only forces me to do more work. When I first learned Swift, I appreciated the Ruby-like conciseness and expressiveness, but it took me some time to grow to love static typing. To see it as a small investment that pays off quickly, and something to celebrate. With this talk, I want to persuade Swift coders that both expressiveness *and* safety are important and awesome in Swift, and I want to give an example of an API implementation that achieves both of these goals. I made a trial run of this topic with a series of blog posts on radex.io, and on two local meetups, and it was very well received. I’d love to evolve and expand this talk and present it in front of a larger audience :)
We'll introduce and explain phantom types while working on a small audio library.
Based on Cheng and Hudak's "Audio Processing and Sound Synthesis in Haskell", we will explore using phantom types to statically encode requirements about sampling rate, leveraging the type system to protect against mismatches. We'll talk about the pros and cons of using phantom types for this kind of task.
Swift on Linux & FreeBSD will allow app developers to write their backend in Swift while re-using existing application code, such as models or utilities. This talk will give an overview and a concrete example of running Swift on a web server.
Swift on the server, that's a new option now that open source Swift is available for Linux and FreeBSD. Not only will this extend the possibilities and reach of Swift, it will also allow app developers to write their backend in Swift while re-using existing application code, such as models or utilities. This talk will first introduce general server development and highlight key differences to app development. We will then discuss the current state of web frameworks available for Swift and assess their performance. Here, we will also see which frameworks are best for certain use cases. Furthermore we will list restrictions, such as only using Foundation & libdispatch, in order to allow the sharing of our code between Swift and Linux. Finally, a concrete backend REST service will be implemented based on an already existing app / model.
During the workshop we will implement together une user stories from scratch for a new iOS application. The code will be written in Swift, but I will also provide information about implementation details in other languages, like Objective-C or Java. Distribution of the contents and scope may vary slightly, in order to maximize the understanding of the bases.
- Clean Architecture Concepts
Brief introduction in order to understand the pieces of the architecture and their implementation in iOS.
- Implementation of the Interactor
Implement the first user story: show a list of data elements to the user. Define the first version of the immutable entities and transform them into immutable structures with the data to display.
- Implementation of the Presenter/event handler
Creation of the presenter that will talk to the view and present the data.
- Implementation of the View
How to make a dumb, but still useful view.
- A basic implementation of the entity gateway
Defer the decision of the persistence framework for later. Implement the minimum functionality in a basic object. Implications of the repository pattern.
- Connect the pieces and make it all work
Understand the way the pieces are interconnected and its memory management implications. Implement the required object, modify the App delegate and make it work with the storyboard. - Proper connections. Writing a reusable way to connect the pieces and navigate.
- Review, Questions & Answers.
In this talk I will describe different approaches to solve dependency injection for an advanced architecture and explain its pros and cons. I will cover from dependency injection containers to the more traditional factories.
I will start by framing the problem: Why is relevant and convenient to use dependency injection. Then I will introduce a realistic scenario and its approach using Swinject with insights about the advantages and disadvantages of using it. Then I will replace that with factories explaining the pattern and how to use it (and how not). This is a talk addressed at people interested in Swift OOAD, design patterns, and advanced architectures.
We would like to share what we have learned from running hundreds of AB tests on mobile at Spotify, and help you start running meaningful tests on your apps.
AB Testing used to be complex experiments only companies like Amazon or Google used to run. The tools available now are simple and enable this strategy even for one-man apps. But, what makes a meaningful experiment that can make your app better? how can failed experiments be still bring value? We want to talk about the science on AB tests in a way that everybody understands and enjoys, and we have some case studies from Spotify to analyze and share. This is a joint session by myself, iOS Developer at Spotify, and Ph.D Boxun Zhang, a data scientist with whom I've worked running lots of tests during the last year, and we have a clear call to action for the audience: these are the basics, start AB-testing!
Building reusable and well structured code is an aim of every developer. However that hasn’t always been easy in the Appleland. Recent changes and discoveries in some of the notsowelldocumented corners of XCode now made development using Frameworks a reality.
We would like to share our experience with building framework oriented apps, walk you through the architectural patterns and then seal this off by creating a project.
The exciting journey of changing your project architecture basing it on Frameworks and allowing developers to start using Swift in the SoundCloud main app.
Since the launch of Swift in 2014 we had used Swift only in the SoundCloud watch app. The need of having reusable business logic among other reasons led to a new architecture for the project based on dynamic frameworks where Swift would be a first citizen member. In this talk we'll explain the approach we followed at SoundCloud to change our app architecture allowing developers to start using Swift in the project. Learnings, caveats, and how the project and the company has benefit from this journey.