A large percentage of mobile apps use SQLite relational databases for persistence (such as Core Data on iOS), but are they always the right option?

NoSQL databases offer a compelling alternative in web applications, but developers seem firmly attached to a relational model on the device. There are a number of scenarios where this can deliver sub-optimal outcomes, such as search performance and data sync. This presentation will cover these issues and present a few alternatives, focusing on practical demonstrations of specific NoSQL approaches on iOS, however the concepts are highly applicable to other mobile platforms.

Last year Apple announced a brand new programming language as a modern replacement for the venerable Objective-C. Swift makes a very interesting study in language design – influenced by modern statically-typed languages with an emphasis on safety and speed, but (almost) seamlessly compatible with the unsafe, dynamic, weakly-typed OO language it needs to co-exist with.

Sam will run through a brief introduction to the language, highlighting some of the design choices and tradeoffs made, and show how to use the language features to write better code.

Laziness is one of Larry Wall’s “three great virtues of a programmer”, but most people probably don’t consider it a virtue when writing tests! Wouldn’t it be great though, if we could write a program that generates our tests for us? As it turns out, we can and should do this using property-based testing.

I’ll go through some example testing scenarios in a few popular programming languages, aiming to demonstrate:

• What property-based testing is and why EVERYONE should be using it (not just people coding in functional languages!)
• How generators can quickly & easily come up with more thorough test inputs than a programmer typing in magic numbers
• How to (and how not to) define properties to specify program behaviour
• The genius of shrinkers and why they can save you hours of tedious debugging and questioning your life choices

Attendees will gain a solid & practical understanding of how they can apply property-based testing to their own code, in fashion that is both enjoyable and lucrative.

A large percentage of iOS apps today use Core Data for persistence, but is this always the right option?

NoSQL databases offer a compelling alternative in web applications, but developers seem firmly attached to a relational model on the device. There are a number of scenarios where this can deliver sub-optimal outcomes, such as query performance and data sync. This presentation will cover these issues and present a few alternatives, focusing on practical demonstrations of specific NoSQL approaches on iOS, however the concepts are highly applicable to other mobile platforms.

TL;DR – If you have callbacks manipulating object state, you have bugs.

Most modern mobile apps are event driven – location, touch events, network calls, push notifications etc can all trigger app behaviour. Traditional imperative approaches to managing these events are difficult to understand/maintain and are a reliable source of semantic bugs in your app.

ReactiveCocoa is an open source Functional Reactive Programming (FRP) implementation for iOS, and offers a better approach to implementing event-driven code. This presentation will show how to use the new ReactiveCocoa 3 to build better Swift apps.

Unidirectional Data Flow is the new hotness in UI architecture, but how do we apply this to mobile apps? The easy answer is “Use React Native”, but who would want to take the easy road? Instead, in this talk we’ll go through the key elements of the unidirectional data flow style and look at how to architect this for mobile using an example Swift iOS app.

This will include:

• Defining core application state and leveraging change events to update the view layer
• Wiring up an Action dispatcher to manage state change, including background event
• Approaches to implement navigation flow on top of the UIKit framework

Attendees will gain a clear conceptual understanding of the Unidirectional style, and the practical benefits & drawbacks they’re likely to encounter using it in a mobile app.

Laziness is one of Larry Wall’s “three great virtues of a programmer”, but most people probably don’t consider it a virtue when writing tests! Wouldn’t it be great though, if we could write a program that generates our tests for us? As it turns out, we can and should do this using property-based testing. I’ll go through some example testing scenarios in a few popular mobile programming languages, aiming to demonstrate:

• What property-based testing is and why EVERYONE should be using it (not just people coding in functional languages!)
• How generators can quickly & easily come up with more thorough test inputs than a programmer typing in magic numbers
• How to (and how not to) define properties to specify program behaviour
• The genius of shrinkers and why they can save you hours of tedious debugging and questioning your life choices

Attendees will gain a solid & practical understanding of how they can apply property-based testing to their own code, in fashion that is both enjoyable and lucrative.

Traditional event-based MVC has been the standard pattern for building user interfaces for decades. However, this pattern has its downsides – specifically, shared mutable state and cascading event chains can lead to code that is difficult to comprehend and reason about.

In this talk we’ll look at alternative approaches that leverage functional programming techniques, using the native mobile app development space to demonstrate. We’ll start by introducing the concepts of declarative UIs and reactive one-way data flow, as exemplified by the JavaScript-based React Native framework. Then, if JavaScript is not your cup of tea, we’ll see how we can apply the same principles using Swift and ReactiveCocoa, a functional reactive programming library for Cocoa.

Irrespective of what language you use or what sort of user interfaces you build, this talk will introduce you to the virtues of reactive one-way data flow and immutable state, and how they can help you write code that is easier to understand.

Traditional event-based MVC has been the standard pattern for building user interfaces for decades. However, this pattern has its downsides – specifically, shared mutable state and cascading event chains can lead to code that is difficult to comprehend and reason about.

In this talk we’ll look at alternative approaches that leverage functional programming techniques, using the native mobile app development space to demonstrate. We’ll start by introducing the concepts of declarative UIs and reactive one-way data flow, as exemplified by the JavaScript-based React Native framework. Then, if JavaScript is not your cup of tea, we’ll see how we can apply the same principles using Swift and ReactiveCocoa, a functional reactive programming library for Cocoa.

Irrespective of what language you use or what sort of user interfaces you build, this talk will introduce you to the virtues of reactive one-way data flow and immutable state, and how they can help you write code that is easier to understand.

Traditional event-based MVC has been the standard pattern for building user interfaces for decades. However, this pattern has its downsides – specifically, shared mutable state and cascading event chains can lead to code that is difficult to comprehend and reason about.

In this talk we’ll look at alternative approaches that leverage functional programming techniques, using the native mobile app development space to demonstrate. We’ll start by introducing the concepts of declarative UIs and reactive one-way data flow, as exemplified by the JavaScript-based React Native framework. Then, if JavaScript is not your cup of tea, we’ll see how we can apply the same principles using Swift and ReactiveCocoa, a functional reactive programming library for Cocoa.

Irrespective of what language you use or what sort of user interfaces you build, this talk will introduce you to the virtues of reactive one-way data flow and immutable state, and how they can help you write code that is easier to understand.

Elm, for a long time the flag bearer of Functional Reactive Programming on the web, recently switched to a simpler pure functional architecture, citing 'ease of use'. Those of us that have worked on complex reactive mobile apps can sympathise with this - using FRP injudiciously in your app can make the code difficult to understand and near impossible for new developers to pick up.

So are we able to apply some of the techniques and patterns from Elm into iOS apps? It turns out the Elm architecture is a really great fit for Swift & iOS - it allows us to:

• reserve our FRP hammer for the use cases that make the most sense
• separate out a simple, consistent, and highly testable pure functional core, and
• provide a flexible, yet easily understood & applied set of architectural building blocks.

This session will cover the basics of implementing and using an Elm-style architecture in a Swift app, will include lessons learnt in a real-world implementation, pitfalls/benefits, and implementation considerations should you adopt the approach in your own app.

Many developers harbour the dream of throwing off the shackles of corporate serfdom and experiencing the glorious freedom of self-employment. So is the grass really greener on the other side? As a developer who took the plunge a few years ago, I can offer some honest feedback and practical advice on things like:

• what to consider when assessing whether self-employment is right for you.
• the different software development business models, the pros & cons of each.
• setting up a business/company - which structure is best.
• knowing when to quit your job.
• pricing yourself correctly.
• sales & marketing - critical activity or soul destroying waste of effort?
• why on earth can’t people just pay you on time.
• what to say to friends and relatives who think you don’t do anything all day.

And generally everything else that I know now, that I wish I knew then.

Elm, for a long time the flag bearer of Functional Reactive Programming on the web, recently switched to a simpler pure functional architecture, citing 'ease of use'. Those of us that have worked on complex RxSwift/ReactiveCocoa apps can sympathise with this - using FRP injudiciously in your app can make the code difficult to understand and near impossible for new developers to pick up.

So are we able to apply some of the techniques and patterns from Elm into Swift iOS apps? It turns out the Elm architecture is a really great fit for Swift - it allows us to:

• reserve our FRP hammer for the use cases that make the most sense
• separate out a simple, consistent, and highly testable pure functional core, and
• provide a flexible, yet easily understood & applied set of architectural building blocks.

This session will cover the basics of implementing and using an Elm-style architecture in a Swift app, will include lessons learnt in a real-world implementation, pitfalls/benefits, and implementation considerations should you adopt the approach in your own app.