If you’ve ever built an iOS app with CocoaPods using the Xcode build and release task in an Azure Pipeline, you’ll know it takes ages. Every additional pod you add seems to add minutes to the build task, and before you know it your iOS app is taking upwards of 30 minutes to an hour to build. This is both an inconvenience when you’re trying to push and test changes quickly, and a massive disincentive to use more pods.
A basic iOS app building Azure Pipeline would probably do something like this:
Apple’s Worldwide Developer Conference, which kicked off at the end of June, brought a slew of software changes to all of its devices. We finally got to see widgets on the home screen of iPads and iPhones, and macOS has received its biggest visual update since macOS Yosemite. But, the biggest announcement was saved for the end of the Keynote, where CEO Tim Cook announced over the next two years, their Mac lineup would transition away from Intel to their own Apple Silicon.
Let’s break down what this means.
In the video ‘Data Essentials in SwiftUI’, published at Apple’s Worldwide Developers Conference, the phrase ‘Source of Truth’ is mentioned a whopping 31 times. So what does it mean? And how can thinking of this principle help you write better SwiftUI apps?
Source of truth is a key concept in SwiftUI, and if you watch Apple’s Worldwide Developer Conference videos, you’ll hear them reiterate this concept over and over. …
One of the first decisions SwiftUI developers need to make is which of the available property wrappers to use to store data. Especially in iOS 14, where the whole app lifecycle can be written with SwiftUI, storing your data the right way is essential to your app running and behaving predictably and bug-free.
The challenge in making a SwiftUI app is technically all four of
@EnvironmentObject will superficially “work”. Your app will compile, and you may even get the behaviour you are after even when using the wrong property wrapper for the situation.
But, if used incorrectly, you may find your view doesn’t update when your data updates. Or, your data persists for longer than you expect it to. Or, your data doesn't persist at all. …
With the release of SwiftUI 2 and iOS 14, we now have access to a new view called ScrollViewReader that exposes an object called ScrollViewProxy. What this allows us to do is programmatically control where a user is scrolled to in a view — and send users to a specific spot in your long view.
To test this out, I wanted to create a custom scroll control using a slider to determine where the user was in the ScrollView. The user would be able to drag the slider, which controls where the user is.
Fortunately, the new views in SwiftUI 2 allow us to do this. …
At Apple’s annual developer conference WWDC in June 2019, Apple announced SwiftUI, a new declarative syntax for quickly creating user interfaces for both iOS, iPad OS and macOS apps. I wanted to get a taste of SwiftUI, in addition to coming up with a solution to a common problem for Melburnians.
To get to work, I need to change trains at Flinders Street Station to get to Southern Cross, a station my train line doesn’t go to. Each morning I arrive at Flinders Street and across the 13 platforms, it's often inconsistent and unpredictable as to where the next Southern Cross train will depart from. So, being a developer, I decided this problem needed an app to solve it. …
Within our app written in Swift and using SwiftUI, we needed a way to read our data from Google Firestore into the app, and then write some data back into Firestore.
Initially, I followed this guide from the Firestore documentation, although it involved a lot of mapping dictionary key/values to the type I was after. Writing data was much the same. For each property in my Swift class, I had to specify the name of the corresponding Firestore field, and then assign the appropriate value to the field. I knew there must be a better way.
Fortunately, the Firestore documentation recognises this problem and offers a way to bring your document into a Swift class, and allow you to use it as you would any other piece of data. This is through the use of the Pod
FirebaseFirestoreSwift , which adds an extension method to the
document.data() call so you can specify what type the data is coming in as. There is also a similar method on the
document.setData() method for converting your Swift object back to a Firestore object. …
Something I always seem to struggle with is trying to get variables into Azure Pipelines
build.yml files. Some variables are predefined and global, and others are set locally. I’m going to compile a list of code examples for my own reference, and grow this list as I learn new ways of doing things.
In this case I want to run a bash script on a Mac agent to rename the built app file to include the version number. To use a predefined variable, you want to use all caps and add an underscore wherever there is a full stop. You also want to add a dollar sign to the start. For example
As someone who has spent most of their (very short) career doing one click cloud resource deployments, I was shocked when I jumped onto a legacy project and realised the complexity of the deployment process to staging and production. Using a traditional .NET Framework application stack, the deployment process consisted of the following steps:
Modern CSS has come leaps and bounds from the days of
margin: 0 auto and
clear:both workarounds of yester-year. After spending too long fiddling with Bootstrap columns and percentage widths, I decided to take a serious look at CSS Flexbox, and I am incredibly impressed with what it is able to do.
Recently I wanted to adjust the number of items in a single row based on the width of that div. I wanted to show the maximum number of items in that row that I could, but as the div width was reduced I also wanted to reduce the number of items shown so each item would maintain its width. …