My Journey to SwiftData

I started developing Bushel in early 2023 and knew I needed a way to get list of the user's virtual machines, restore images (for installing the OS), snapshots and other entries. My apprehensiveness came from the format of Core Data. At this point, I don't want to use an API which uses XML over Swift. I had used Core Data for a client application previously in the early days of Swift 1 and was pretty familiar with using it. Additionally I would consider myself well versed in Relational Databases and SQL, so I am very comfortable working directly with SQLite too.

Eventually I did go with SwiftData and have written about it before:

• SwiftData CRUD Operations with ModelActor
• Being Sendable with SwiftData
• Using ModelActor in SwiftData

My reasons for going with SwiftData include:

• I wanted to work within Apple's confines
• I saw value in adopting ORMs
• I wanted to use newer technology in the long term

Working within Apple's APIs

There are advantages and disadvantages to working within Apple's playground of APIs. Here are a few questions to ask yourself:

Are you working with technology particular to Apple hardware?

If you are working with a technology that is Apple-centric then it may be best to stick with Apple's API. Over the long term, Apple is good at sticking with that API as hardware changes. If you use a more direct approach, you are dependent on yourself or third-party developers to keep up with updates (see Flutter and React Native).

However, there is a small risk that Apple will softly abandon an API. When I say softly abandon, I mean no new WWDC videos, no bug fixes, and no new documentation. For example, Combine has not had many updates since its release in 2020. This could mean it is no longer the preferred way to interface with SwiftUI (see Observation). However, in reality, an experienced team in reactive programming which may need to support older OSes sees benefit in adopting this API and it's still the underlying basis for much of SwiftUI. So while adopting Combine now may be riskier, adopting it in 2020 doesn't seem like a bad choice.

A better example are UX-centric APIs such as 3D Touch, WatchKit, complications, visionOS, App Intents and more. These are technologies which were in early infancy and are likely to have a lot of changes.

The other issue is documentation. Apple has improved a lot when it comes to documentation; however, there are blind spots when it comes to certain APIs and not just for abandoned APIs:

• Advanced applications with many integrations
  • a great example of this is SwiftUI in dealing with multiple views or navigation as well as the lack of guidance when it comes to testing
  • Missing unclear definitions of properties, parameters, and usage
  • Hidden or difficult to find limitations of abstractions and APIs such as Web Sockets on watchOS
  • purposeful agnosticism

What I mean by purposeful agnosticism is that in some cases Apple doesn't want to impose a particular pattern which in many cases makes sense. Developer patterns really depend on the application, the team, and their skill level.

Having said this, I do highly recommend taking advantage of forums, sessions, feedback and other ways to contact developers at Apple. They are friendly and very helpful when it comes to certain issues.

As a developer in public myself, I'm glad because otherwise we can't sell and publish so many blog posts, courses, videos, and books!

Are you willing to deal with the challenges of Apple's abstraction?

In some cases, Apple's abstractions can be more of a challenge than a benefit. Personally, I disagree; however, I totally understand the friction other developers run into, especially if you are skilled in a more direct approach:

• Why SwiftUI? - I know how to interface directly with the UI - Flutter, Core Graphics, UIKit, etc...
• Why SwiftData? - I know how to interface directly with a SQLite Database - Core Data, SQLite libraries etc...

However, that can come with a risk. More so than Apple abandoning an API, Apple doesn't care about your direct implementation. What this means is that if Apple changes hardware - you will need to change your implementation with it. This is especially problematic for UI.

In the early days of iOS development, it was considered reasonable that devices would be the same size forever. However, as device screens grew, iPad was introduced, and new display paradigms were introduced (the notch, dynamic island, etc...). This meant that third-party APIs which assumed consistency had to continually stay up to speed. In the end, it's something to consider when using an API, library or just writing code closer to the metal.

Regarding Local Storage

Before deciding to go with a local storage type, make sure you really need one. Just as with a backend, if you can avoid it, try to.

• Do you need offline access?
• Can you just use a backend solution?

Additionally, consider if User Defaults might suffice. This was the approach I made with Bushel at first until the release of SwiftData. It was clearly not the right choice for me but in some cases, it may be enough.

Besides going with an Apple framework or not, here are a few considerations. What is your team well versed or should be well versed in? If you're not a team (i.e., indie application) you have a lot more flexibility, in which case the frequency of maintenance and update of the framework you choose is important. If you and your team are well-versed in SQL and perhaps you want to use the same thing for your Android app, that may make more sense. If your team is very knowledgeable in Core Data, then that might be the way to go.

We've gone over the reasons to go with Apple's ORM Frameworks vs SQLite. The question next becomes whether you should go with Core Data or SwiftData.

Core Data vs SwiftData

In regards to SwiftData vs Core Data, it comes down to a few questions:

• How green is your app?
• Are you willing to stick with it and its updates over the years?
• Are you willing to deal with the limitation of abstractions contained within SwiftData?

Green vs Brown

If you're starting off without any sort of local storage and don't need to support operating systems before 2023 and use SwiftUI, there's very little risk in going with SwiftData. Unless you really don't trust Apple and think that Core Data's more concrete API is required, I would go with SwiftData. Much like SwiftUI's adoption, its first releases weren't perfect but going with it in the long term gives many advantages. Those advantages include adoption of new device paradigms and easier hiring for new developers (see my Objective-C video). At some point then you may need to update from Core Data to SwiftData which can be a challenge. SwiftData integrates with many new technologies which Core Data is not even aware of. These include SwiftUI, Macros and of course Swift 6.

Swift 6, Macros, and SwiftData

One of my biggest complaints with SwiftData is how tightly coupled it is with SwiftUI through the @Query macro. As I transitioned to DataThespian for more of a ModelActor approach in Bushel, I found @Query to either be insufficient or run into conflict with what @Query is doing. At this point, Bushel doesn't even contain @Query properties anymore because of the issues I was running into.

My point is that at the time of writing of this point, there will be friction as you do more advanced operations - that's why I wrote a whole library for working with ModelActors. Dealing with macros for instance, can result in code compilation issues you may need to deep dive to understand. Most of all is the issues you may run into dealing with Swift 6.

If you are moving to SwiftData, it may be worth considering a move to Swift 6. If you have a fairly large app, perhaps creating a separate Swift 6 module which deals with SwiftData would be worth your time.

Alternative Choices

Before closing out, I wanted to post a list of useful Swift Packages:

I love SQLite

• groue/GRDB.swift: A toolkit for SQLite databases, with a focus on application development
• stephencelis/SQLite.swift: A type-safe, Swift-language layer over SQLite3.
• pointfreeco/sharing-grdb: A lightweight replacement for SwiftData and the Query macro.
• groue/GRDBQuery: The SwiftUI companion for GRDB

I love better abstractions

• mergesort/Boutique: ✨ A magical persistence library (and so much more) for state-driven iOS and Mac apps ✨

I love Core Data

• JohnEstropia/CoreStore: Unleashing the real power of Core Data with the elegance and safety of Swift

I love SwiftData

• fatbobman/SwiftDataKit: SwiftDataKit allows SwiftData developers to access Core Data objects corresponding to SwiftData elements.
• brightdigit/DataThespian: Concurrency-Friendly SwiftData

Final Thoughts

In the end, I would go with SwiftData. If you are willing to wait a few months, it could be worth it but my reasons right now are:

• I trust Apple's long-term commitment to an API which is used by a plethora of Apps
• I prefer ORMs over direct SQL statements
• anything which migrates Xcode non-Swift files to Swift-based code is preferred (i.e., Storyboards, Core Data Models, Xcode projects)

I'd love to know your thoughts on this. You can reach out to me on social media if you think I'm missing something when it comes to my decision process.

At the time, Swift was primarily known as an iOS development language, so the concept of using it for cloud applications seemed unusual. This workshop introduced me to Kitura, but it was when I discovered Vapor that everything clicked - I found it was fast, simple, and leveraged all of Swift's advantages.

The Birth of Heartwitch

As a Nintendo Switch enthusiast who enjoys working out while gaming, I noticed something interesting in the speedrunning community - streamers often display their heart rate during runs.

This observation sparked an idea: what if we could create a system to livestream heart rate data in real-time?

The initial implementation was straightforward:

1. Collect heart rate data through HealthKit
2. Send data to a Vapor server via POST requests
3. Transmit data to browsers through WebSockets
4. Display the heart rate overlay using OBS for streaming

I named this project Heartwitch (a name I'd later reconsider), allowing streamers to share their heart rate data during gaming sessions.

The Pandemic Pivot

In early 2020, the pandemic transformed how people approach fitness. As gyms closed and home workouts became the norm, I received an interesting email from Chris, who saw potential in adapting Heartwitch's technology for fitness instruction. The idea was compelling: help instructors monitor students' heart rates during remote classes, or allow instructors to share their own metrics while teaching.

Enter gBeat

This pivot led to the creation of gBeat, a comprehensive fitness streaming platform. The core functionality includes:

• Real-time heart rate monitoring
• Instructor-student connectivity
• Automated workout session management
• Cross-platform compatibility
• Integration with various fitness platforms

Why Server-Side Swift?

Choosing Swift for both client and server offered several advantages:

1. Code Sharing: Common models, networking code, and business logic can be shared between iOS, watchOS, and server components
2. Type Safety: End-to-end type safety across the entire stack
3. Familiar Tooling: Using Xcode and Swift Package Manager throughout the project
4. Performance: Swift's strong performance characteristics on both client and server
5. Apple Ecosystem Integration: Seamless integration with HealthKit, Push Notifications, and Sign in with Apple

Architecture Overview

gBeat's architecture consists of several key components:

The server handles:

• Authentication and session management
• Real-time data streaming via WebSockets
• Push notification distribution
• Workout session coordination

The client side manages:

• HealthKit integration
• Local workout tracking
• UI/UX implementation
• Real-time data synchronization

Looking Forward

The journey from a simple gaming stream overlay to a full-featured fitness platform shows how Server-Side Swift can scale from hobby projects to production applications. In the next post, we'll dive deeper into the technical implementation of authentication using sign in with apple and development challenges.

My 2024 Journey

This year was pretty huge for me personally. I got to speak at the Server-Side Swift conference in London and even made it to a WWDC side conference. My first time at WWDC. But that wasn't all - my family and I decided to make a move (don't worry, we stayed in the same town), and I made some big changes in my career path too.

So... How Was the Job Market?

2024 was tough for tech folks. Three big things really shook things up:

• Those sky-high interest rates had companies playing it super safe
• Everyone was both excited and nervous about AI
• We're still dealing with that post-COVID hiring spree

Even more frustrating - ghost posts became a huge thing this year. These are job listings that companies put up without actually planning to hire anyone. With HR teams getting hit by layoffs, the whole hiring process became a mess. I found those job board posts were a waste of time - it was all about personal connections.

Apple's 2024: Hits and Misses

Remember when the Vision Pro launched back in February? And then Apple Intelligence came along? Unfortunately neither were a smash hit. The Vision Pro's $4,000 price tag was pretty hard to swallow and developers weren't rushing to make apps for it.

However, the redesigned M4 Mac mini was a big hit showing that the Mac is still very popular. Financially, Apple services (you know, iCloud, Apple TV+, Apple Music) are still going strong. With the announcement of Swift-Java interop, I'm sure Apple is moving much of their older Java-based services over to Swift. Good news for Swift developers!

What Developers Actually Cared About

Looking at what people were clicking on and listening to this year:

SwiftUI is still the star of the show. Anything SwiftUI-related just blows up! Whether it's tips on moving from UIKit, dealing with state management, or creating cool animations, it seems you can't get enough.

Swift 6 got everyone talking too, especially with more thread safety being introduced. Having Matt Masicotte on the podcast to chat about it was always a hit.

Lastly, people are very interested in software architecture. This makes sense whether it's improving the maintenance of your app or upgrading your career.

Career Changes and Future Plans

With all the challenges in finding new contracts and having just purchased a new home, I made the decision to take on a full-time position. I've been at it for over a month now, and it's been great - steady paycheck, benefits, and I'm working with a fantastic team I already know from previous work.

This change doesn't mean I'm stopping my other work though. I'm just approaching it differently. For app development, I'm going to focus on smaller apps and implement Jordi's 2-2-2 method. I'll continue updating my existing apps, including the ongoing rewrite of Heartwitch (soon to be rebranded as Bitness).

Bushel development will continue in 2025, and I've got some exciting plans there. I've already started open-sourcing parts of the codebase:

• DataThespian My library for interfacing with SwiftData using model actors for background operations
• RadiantKit A collection of reusable SwiftUI views from Bushel
• BushelKit The core open-source component that enables CLI access and third-party development

I'm also wrapping up PackageDSL, which helps create large and complex Swift packages more easily.

As for the podcast, I'll be more strategic with the schedule. The analytics showed that months around WWDC and September's iPhone release are the busiest, so I'll focus more content during those periods and take breaks during quieter months.

Looking for Subcontractors and Community Involvement

Even with my move to full-time work, BrightDigit's work isn't stopping. I still have existing clients and new opportunities coming in, which is why I'm actively looking for subcontractors. If you're an iOS developer, especially with experience in macOS, watchOS, HealthKit, or Server-Side Swift, I'd love to hear from you. Experience with VueJS or TypeScript is a plus too. You can reach out to me with your resume and availability.

Thank You

I want to thank you, the audience, for being such an inspiration to me throughout 2024. Your engagement and feedback have really driven me to keep creating content and sharing my thoughts about Apple development and Swift. Special thanks to my Patreon supporters - your contributions have been fantastic, and I really appreciate you being early readers of articles and tutorials like this one.

Looking forward to continuing this journey together in 2025. If you have any suggestions or topics you'd like me to cover, please reach out. And hey, if you enjoy the content, consider subscribing to my newsletter or leaving a review for the podcast - it really helps!

What's New in Bushel v1.2.0?

Enhanced Performance

We've made significant performance improvements to prepare for Swift 6, ensuring a smoother and faster experience.

WishKit Integration

We're excited to introduce WishKit integration, allowing you to request and vote on new features directly within the app.

Improved Document Management

Managing your machines and libraries has never been easier. Bushel now keeps track of moved and deleted files more efficiently.

Advanced Error Tracking and User Feedback

With improved error tracking and a revamped user feedback system, we're committed to making Bushel as robust and user-friendly as possible.

Brand New Machine Creation Dialog

The machine creation process has been completely redesigned for a more intuitive and streamlined experience.

Improved Installation Screen

We've enhanced the installation screen with more descriptive progress indicators, so you always know what's happening.

Celebrate with a 50% Discount!

To celebrate the release of Bushel v1.2.0 and WWDC 2024, we're offering a 50% discount on the first year of Bushel Pro, bringing the price down to just $31.99. This offer is available for a limited time, so don't miss out!

Sign up for the Bushel TestFlight Beta and be among the first to experience these exciting new features. The release version is available on the App Store, but you can also join the beta by signing up on our website.

Meet Me at WWDC 2024!

I'll be around for WWDC 2024 and would love to meet you! I'll have Bushel stickers available for anyone who finds me, so be sure to say hi.

Looking for Help in 2024?

I'm also available for new projects in 2024. If you need expertise in Swift and the Apple ecosystem—whether it's iOS, macOS, server-side, watchOS, Vision Pro, or Apple TV—reach out to me here. I look forward to helping your team succeed.

Thank you for your continued support and enjoy exploring Bushel v1.2.0!

Dependency management in Swift is essential to maintaining the stability and security of your apps. It’s necessary if you’re going to build an app on time and budget. Done well, it avoids breaking issues, But as Brandon Williams from Point-Free pointed out in my conversation with him on EmpowerApps, we often underappreciate how much we rely on and compromise with other people’s code that we can’t control.

In this article, I’m covering what effective dependency management in Swift is, how it can make further development of your apps easier, and strategies for mocking dependencies during testing.

What is a dependency in Swift?

Despite most of us having a definite idea of what a dependency is in our minds, it is more than what you think. In the broadest sense, a dependency is anything in your app that requires an outside system that you do not directly control.

While we don’t usually refer to it as such, even Apple’s own code is a dependency within our apps or any time we touch an API, a clock, a file, a database or a date initializer. Even Apple’s own hardware is a kind of dependency. We don’t have any control over it or how it’s made – we can only trust that it will work because it’s in everyone’s interest that it always works and be ready for us. Often, we don’t think about something like Core Location as a dependency simply because we don’t add it as one in our applications.

Why is dependency management important for testing?

Mocking is an important part of testing with any dependency. As a general rule, you should be mocking anything that’s persistent or external. If you’re testing components that aren’t yet ready for your production app, mocking is a simple way to isolate this code for testing.

The real power of well-controlled dependencies is you can quickly and accurately predict what should happen in testing. If you have lots of code constantly calling for external resources, like location data or network requests, you’ll probably make your work very difficult for yourself. You might also make it impossible to effectively unit test those components of your app.

The most important thing to remember is to test how your code deals with various results, both passing and failing, and what is returned. Your goal should be to test code behavior based on what you need to get from a call.

So what do you need to know: if you’re making a call and expecting data to come back, then you need to focus on how that data is filtered and changed into something your app can use. You can only test that by having some control over the dependency.

If you’re new to unit testing in Swift, you’ve probably struggled with managing database and network calls. A lot of people fall into this trap and slow themselves down. A great way of escaping this trap is to think of it like you’re dealing with Apple’s own code. No one tests Apple’s APIs – we trust that they will work because it’s strongly in Apple’s interest that they do so. All you need to do is mock the data that you trust you will get.

XCode Previews

XCode Preview is worth mentioning here as, like unit testing, they’re a valuable way of testing views without spinning up your whole app. While they are similar in a general sense, Previews also present a couple of challenges:

The first thing is that the more you add to your project, the more likely you are to break your preview. To avoid that happening, you want to, as much as possible, break your projects up into lots of small, stable modules. This uses the principle of microapp architecture (also known as modular architecture). This has the added benefit of making it much easier to scale your app later on without sending your build time sky-high.

The other challenge is that there are a lot of APIs that will also break your preview. If the user needs to grant permission for something to work, XCode Previews doesn’t support that – it’s just how it works. So, if you need to iterate your views, you must find a way to mock the dependencies.

How to Mock Dependencies

In my chat with Brandon Williams, a fellow Swift programmer on EmpowerApps, we discussed dependency control. Brandon has a great way of framing how to weigh different considerations when mocking dependencies as a tradeoff between ergonomics and safety.

In this context, ergonomics means how it is designed to make it easy or comfortable for you as a developer. Brandon uses the example of the UserDefaults class – an easy way to store a user’s preferences and optimize your app’s behavior to them.

On the other side, you have safety. By its nature, Swift is a strong and safe language – variables are always initialized before use, memory is automatically managed, and exclusive access to memory protects you from many coding mistakes getting into your production app.

It is impossible to have an app that is both perfectly ergonomic and safe. It’s always a compromise. Brandon uses the example of providing initializers for all your variables with no defaults, which is extremely safe but will be a huge pain run in testing.

A reliable strategy for finding a balance between ergonomics and safety is with a dependency injection framework. The most popular ones all cut a different balance between ergonomics and safety, so which one you use will come down to what you need to test, the requirements of the project, and your own professional preference.

Protocols are not the only way (to pass a single function)

Protocols are the most popular way of putting your interface in front of something, but not the only way. If you only have to pass a single function as part of your mock – say, if you needed to mock access to a network – then it’s easier and simpler to pass the function rather than mocking a protocol to declare it.

So instead of:

protocol Adder {
    func doTheThing(x : Int, y: Int) -> Int
}

struct TheThing {
    let adder: Adder
}

You can just pass the function without the need for the protocol.

struct TheThing  {
    let adder : (Int, Int) -> Int
}

You substitute in for a protocol. When controlling for dependencies, you commonly will have only one or two implementations – one live, one mock. It ultimately simplifies mocking and doesn’t get you bogged down with the features and powers of protocols, which can make your life easier if you need to mock or test a function quickly.

Special thanks to Brandon Williams

Thanks again to Brandon Williams, whose thoughts and conversation were valuable in putting this article together. If you enjoyed this article, I encourage you to listen to my conversation with him on EmpowerApps. Brandon publishes videos on advanced Swift through his own brand, Point-Free, which are always worth a watch.

Software architecture is the term developers use to describe how major components of an app work together. Modern software structure and design are usually too complex for one person to easily think about all at once. So we use architecture as an abstraction, drawing parallels to traditional architecture, where software has inherited ideas of design patterns and user-centered design. In practice, software architecture means the parts of the app you need to get right.

Well-planned architecture for your iOS app starts with investing lots of time in planning and pays off over time. If you start early, you can create a clear, shared understanding between you and your developers around your app’s architecture. If you do it well, you save lots of time and money over the lifecycle of your app.

In this article, I cover three essential concepts for good iOS software architecture:

• Patterns and Practices
• Code Modularization
• Code Quality

I’ll be explain a bit about each and how to implement them correctly in your app.

iOS Software Architecture Patterns

Choosing a certain architecture for your iOS app determines the design of different aspects of its software. Within that, you’ll also figure out what kind of design patterns you will want to use. A software pattern is essentially a common response to a recurring problem.

Patterns are particularly useful when working with a large team of developers. They can make your developers substantially more efficient at solving problems. It also guides new developers on how to add features to an app. Patterns ensure changes to the code are consistent and reduce risk when making major changes.

Good use of architecture patterns make it easy for developers to understand the software. If it’s easy for them to understand, it’s easier for them to make changes. This means new features can be delivered faster, with fewer bugs and simpler fixes.

There are a few architectural patterns that are very useful when making iOS apps:

Protocol-Oriented Programming

This is a fundamental pattern for developing any app written in Swift (i.e. all native apps on any Apple platform). Protocols allow you to group functionality and define how your data and objects work together. This pattern is sometimes referred to different names, most popularly Interface and Contract or Design By Contract.

Protocols are useful for creating functionality in your app while making the lives of your developers easier. Instead of building a whole new object you can define protocols for new developers to implement. This makes it really easy to reuse objects throughout your code. Protocols also make it easy to separate your app’s behavior from its data, usually referred to as separation of concerns.

Finally, designing your app around protocols makes it easy to test the different parts of your app for the purposes of Test-Driven Development, which I cover below.

Reactive Programming in iOS Software Architecture

This pattern has become popular since the introduction of SwiftUI, which encourages developers to use both functional and reactive programming. Similar to functional programming, reactive programming is the concept of designing your app around events. An event is anything where an input of data triggers a routine within your app. This could be a keystroke from the user, a signal from a connected device such as a sensor, or an alert generated by the software itself.

Apple introduced the Combine framework in 2019 and the Observation framework in 2023 to help iOS developers with reactive programming. These allow you to modify and update values as they come in within your UI. Additionally, these can be used with Model-View-ViewModel (MVVM), which removes the Controller in the MVC pattern mentioned above. WithMVVM, the Controller is replaced with a ViewModel. The ViewModel automates how the Model can be rendered directly into the View by making changes to the Model data and reacting accordingly. This is particularly useful for iOS apps that need to use a resource library that isn’t written in Swift. It allows you to bridge from another programming language into Swift.

Delegation and MVC with iOS Software Architecture

Delegation is an older pattern inherited from Objective-C and UIKit which we use in iOS user interface (UI) development for displaying information in an app. Model-View Controller (MVC) uses Delegation and is historically the most used iOS software architecture pattern for developing Apple apps. With the rise of SwiftUI though, delegation is beginning to decline in popularity. This is how it works:

1. A user performs an action within the user interface (i.e. View).
2. View passes it to the Controller.
3. The Controller makes decisions about what to do with the action it's been given. If needed, it makes changes to the state of the Model, which will change its data values in response.
4. The Controller then sees these new values and sets them for View, showing them to the user.

Delegation allows you to control how the Controller provides both the data and the way that data needs to be displayed to View in the final step. This makes it easy to break apart the functionality of the code to display information to your user the way you want.

Why Code Modularity Matters in iOS Software Architecture

Another key component of great architecture is modularity.

Modularity is the idea that different parts of your app should be able to work independently of each other. This makes it easier to both test and reuse pieces of code in different parts of your app. It also makes it easy to use the same piece of code for different platforms, so your iOS code can work on any Apple platform.

There are three ways I recommend for creating modularity in iOS app development:

Framework Targets

In Xcode (the development environment for macOS), Framework Targets are a way to easily move your app’s code from the testing environment where it was built to the production environment your users can see. Ordinarily, you have to swap out all the URLs and APIs from the testing version of your app to the production one. With Framework Targets, this is done automatically.

Projects and Workspaces

You have a specific piece of code that doesn’t fit into an existing framework but might be used in many apps. The way to deal with this is to have more than one project and workspace. This allows you to organize pieces of code and show how they are related to different development projects.

Swift Packages

The newest and simplest way to achieve modularity. Apple is encouraging a shift toward using only Swift for new apps. This means Packages is essentially the default for creating modularity for iOS apps. If you’re interested in learning how to use Continuous Integration with your Swift Packages, check out our developer article here.

If you’re interested in learning more, check out my more in-depth article on micro apps and code modularity.

Why Maintaining Code Quality Matters

If you’re serious about app architecture and structuring your app well, it pays to also think about how you maintain your code. If you have high-quality code, it makes development faster, easier and cheaper.

There are two great ways to ensure high-quality code:

Test-Driven Development

I’ve previously written about Test-Driven Development (TDD), which you can find here. Committing to good testing and setting up a good testing environment is one of the most powerful things you can do to make your code top-notch.

Ensure Good Code Coverage

Code coverage, measured as a percentage, refers to how much of your app’s code is executed during testing. A high degree of code coverage indicates a low number of possible undetected bugs in your app. This is a great measurement for determining code quality, although you shouldn't be too strict about it. While it’s obviously great if you reach 100% coverage, it might come at a cost when there are more important things you could be doing to serve your users.

Complexity

In software development, there are two kinds of complexity we want to observe and measure:

Cyclomatic Complexity – this metric looks at the number of linear paths it is possible for data to take through your app’s source code. While there are going to be times when it's necessary to have many paths, you generally want to limit this kind of complexity. The reason is that more paths mean needing more test cases to make sure they all work, and more paths mean more opportunities for bugs.

Cognitive Complexity – this metric simply refers to how easy it is for people to understand your code. Easy-to-understand code is always going to be easier to maintain. This is especially true if the person who wrote the code and the person maintaining it are different people.

Overall, keeping your complexity low by limiting file and function length means adding features and fixing bugs takes less effort.

Code Reviews

A code review is when someone other than the code’s creator reads the code, looking for errors or anything unclear. While simple to do, this often gets missed because it takes time to sit down and review code someone else has written —time you might feel you don't have. Having someone review what you’ve written is a great way of spotting mistakes and ensuring better-quality code.

Continuous Integration

This is something I’ve written about previously, explaining what Continuous Integration (CI) is and why it’s important. If you can deploy code frequently, it means you can deliver features more rapidly.If there are problems or bugs, you discover them earlier and faster. CI is also a great way to shorten the time it takes to get feedback from your users.

The Components of Good iOS Software Architecture

By putting in the time to think through the architecture for your app using effective patterns and modularity, as well as following good code quality practices, you will find:

• bug fixes become easier;
• adding new features becomes straightforward;
• your app becomes easier to test and maintain; and,
• your developers will have an easier time understanding the code.

I believe these are things we should all try to observe. You’ll find it not only improves the morale of your developers but also saves you loads of time and money in the long run.

It is very easy for me to sink days into Xcode worry about a bug that users may or may not notice as opposed to letting people out there even know about my app.

• Part 1 - From Seed of an Idea
• Part 2 - Building the Crust
• Part 3 - Design, Architecture, and Automation
• Part 4 - Making Cider from Apples

• Obligatory AI Section
• What's Next
• Thank You

One of the first steps when starting Bushel was to create a website that was easily updatable and an email list for future users (and beta testers) of the app. For the email list, I used formspree until I had TestFlight up and ready. For building the website I went with Eleventy which I’ve grown to love for its simplicity and expandability.

Additionally I setup a Slack for beta testers as builds began to go out in the public. This was a big help getting Bushel into people’s actual hands and hearing their reactions and questions.

Obligatory AI Section

A blog post can’t be finished until I mention AI and in particular ChatGPT. Did I use it for Bushel? yes! And... No!

Code help from ChatGPT was not great. For simple algorithms, that is something which is easily explainable and generic (not Apple API specific); it was fine. However where it really falls short is specialized niche Apple APIs that have changed or been updated over the years … and that’s a lot.

For instance in the case of measuring disk space for a directory it would give contradictory code with parameters or flags which don’t exist. (Regardless I can’t measure the size of a `NSFileVersion so the math is useless.) However some pieces of code were very help or at the least good starting points for me to work with. What makes right now for good instances are ChatGPT prompts which:

• are formulaic in input and output
  • Turn this into a ViewModifier
  • Make a Swift…case statement which returns SFSymbols for Virtual Machine State
  • Turn this into a stringdict
  • Common enough to have been part of the Model (i.e. SwiftUI)

Where ChatGPT was most helpful was in copywriting (i.e. marketing and application text).

As someone who is developing the app, it can be very difficult to come up with the right words to explain something just as it would be for a fish to describe the water they are swimming in.

ChatGPT gave me the ability to concisely explain what I am trying to convey to user. While ChatGPT may hallucinate with certain answers I have the ability to redo my prompts, clarify with further questions, or ask for more answers or examples. This also means I’ve been able to build a lengthy dialog with ChatGPT so it can learn about the app as I continue to ask questions and prompts for more text in marketing material, application copy, or AppStore requirements.

This is big help for me as a developer who may have a difficult context switching to being copywriter on occasion.

What's Next?

My hope is that 1.0.0 is a foundation for building a future for Bushel. I am sure there will be bugs but new features are essential to the future of Bushel so here's a few:

Separate Command Line Tool

This would be a separate command line tool to manage files used by Bushel such as machines and libraries. Part of that would also include...

Partial Open Sourcing

Open sourcing section of the app which are used by a separate command line tool would allow for easy installation and setup. As well as enourage outside expansion, perhaps via...

ExtensionKit

The possibility of allowing developers to extend Bushel in certain spots for custom behavior and integration. Additionally it can encourage ...

More Integrations

More integrations to other VM systems and hubs. The work by the Cilicon and Tart teams are very interesting as well as integrating other online repositories for restore images such as IPSW.

Bushel Service

There are several parts of the service which I need to research:

• XPC for better handling of Bushel as a service
• Vapor for remote and local calls to the service
• Background Tasks for monitor updates to files outside of Bushel
• Menu Icon for easy access outside the app windows

Each of these would be a slow integration into Bushel in order to ensure a stable interface.

UI Updates

Lots of the UI could use updates and an improved design. There are things I did not get to complete in this version which I had in the initial designs so including these would be great. I also hope to use more notifications for longer processes which would be helpful to the user.

Screenshots, Videos, and SharePlay

Being inspired by RocketSim I want to include more features for taking screenshots, videos but also shared somehow via some API (SharePlay, streaming, or any method available).

Bushel Guest Tools

A non-sandbox app, you'd install on your VM to give everything you need to reliable test and debug an application on the VM. This would also include better integrations with Bushel for more customization of software on the VM.

Thank You!

Lastly I want thank all of you for reading this article and learning about the process of building Bushel since day one. With your support you've help make this app a reality. I am looking forward to continue building on top of it in 2024. Feel free to reach out to me on social media if you have any questions, comments, or feature requests.

• RocketSim
• Pixelmator
• Xcode
• Simulator
• Final Cut Pro

I tried to avoid in this version any other Virtual Machine app (except for Docker I suppose which I use nearly all the time). This meant I did not use Parallels or VirtualBox as well as the highly acclaimed VirtualBuddy by Guilherme Rambo.

• Part 1 - From Seed of an Idea
• Part 2 - Building the Crust
• Part 3 - Design, Architecture, and Automation
• Part 4 - Making Cider from Apples

• Microapps
• PackageDSL
• FelinePine
• Murray
• XcodeGen
• GitLab CI
• Fastlane
• If a tree falls in the forest...

The biggest design restriction was that it needed to play along the rules of a Sandboxed app. Therefore every file used in the app must go through a file dialog of some sort and that the app must save the bookmark data for the file. In my case in the Swift Data database. Sandboxing would also become an issue as I used a Microapps architecture for the application.

Microapps

Microapps architecture means I would create separate apps for each part of the application. Additionally Swift Package was used for nearly all the code in the application. The exception being one code file which is the entry point for the application:

import SwiftUI
import BushelApp

@main
struct BushelApp: Application {
  @Environment(\.scenePhase) var scenePhase
}

The Microapp parts of the application are:

• Machines
• Libraries
• Hubs
• Market
• Onboarding
• Settings
• Welcome

It was also important that specialized Apple components or anything shared accross these parts were in separate targets. This includes:

• SwiftUI, Observable and other UI Components
• Database (SwiftData Models)
• Shared SwiftUI Environment Variables
• Other specialized Apple components (such as StoreKit)
• All Virtualization framework code

The app was built with the intention of allow other virtual machine systems to be integrated in the future. On top of the additional supporting or core targets, this means there are currently 52 targets in the Bushel Swift Package.

In order to facilitate either building of microapps, I used XcodeGen to create a project for each target.

This worked really well until I started using bookmark urls from Sandboxing. Once I did that, I no longer had access to the same urls and the micro apps would crash. (Humorously there were no issues with sharing the Swift Data database.)

Otherwise the use of MicroApps has made it much easier to keep concepts and sections of the app separated. I am the kind of developer who prefers things in the smallest pieces as possible: small files, small types, small functions, small targets, etc…

However it made the Package.swift file quite cumbersome to manage. This is where PackageDSL came in.

PackageDSL

I was inspired by the work of Josh Holtz and his DeckUI library to create a (SwiftUI-like) DSL for Swift packages. This was the origin for PackageDSL. This would allow for:

• individual files per target, dependency etc… ensuring small files
• removal of boilerplate code
• encourage best practices for Swift packages
• easy to understand organization

Now it became much easier and faster for me to create new targets. And with smaller targets comes:

• improved build speed
• improved separate of concerns (and testing)
• easy to maintain structure

The only requirement is some boilerplate support files and a simple bash script to concatenate all the files in the directory I store my Package metadata into so it will create a usable Package.swift file.

#!/bin/sh

# package.sh

echo "⚙️  Generating package..."

if [ -z "$SRCROOT" ]; then
  SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
  PACKAGE_DIR="${SCRIPT_DIR}/../Packages/BushelKit"
else
  PACKAGE_DIR="${SRCROOT}/Packages/BushelKit" 	
fi

cd $PACKAGE_DIR
echo "// swift-tools-version: 5.9" > Package.swift
cat Package/Support/*.swift >> Package.swift
cat Package/Sources/**/*.swift >> Package.swift
cat Package/Sources/*.swift >> Package.swift

FelinePine

The only outside library I used (and developed) was FelinePine, a logging library I developed. FelinePine allows me to easily designate the category for each class I use.

internal struct VirtualMachine: Loggable {
  internal typealias LoggingSystemType = BushelLogging

  // set the logging category for VirtualMachine to `.machine`
  internal static let loggingCategory: BushelLogging.Category = .machine
  
  func run () {
    // use the `.machine` logger to log "Starting Run"
    Self.logger.debug("Starting Run")
    ...
  }
  ...
}

I've been developing it off and on for a year and I think it could be fairly useful to folks in the community.

Murray

In Xcode, if you’ve ever created a new file in a Swift Package, you’ve probably had issues with the file name or content.

This is where Murray comes in. As I talked about in a previous episode, I used Murray for several templates including new Swift Package targets via PackageDSL:

//
// Bushel{{name|firstUppercase}}.swift
// Copyright (c) 2023 BrightDigit.
//

struct Bushel{{name|firstUppercase}}: Target {
  var dependencies: any Dependencies {
	BushelCore()
	BushelLogging()
  }
}

Or creating a new SwiftUI View:

//
// {{name|firstUppercase}}View.swift
// Copyright (c) 2023 BrightDigit.
//

#if canImport(SwiftUI)
  import SwiftUI

  struct {{name|firstUppercase}}View: View {    
    var body: some View {
      Text(/*@START_MENU_TOKEN@*/"Hello, World!"/*@END_MENU_TOKEN@*/)
    }
  }

  #Preview {
    {{name|firstUppercase}}View()
  }
#endif

As someone comfortable with the terminal, this makes it much easier for me to create entire new features in Bushel. Additionally since it’s a Swift Package, there's no need to let Xcode know about the new file since package directories are automatically parsed. When I do need to make changes to Xcode projects that’s where XcodeGen comes in.

XcodeGen

Using XcodeGen makes this an even better match since I can have XcodeGen run the PackageDSL script each time it creates a new Xcode project:

name: Bushel
options:
  preGenCommand: ./Scripts/package.sh
...

XcodeGen really is the glue holding together the Swift Package, Xcode, and Fastlane. XcodeGen allows for simple repeatable creation of the Xcode projects for easy development. At some point I may transition to Tuist, especially as PackageDSL is so Swift dependent - I may as well transition from YAML to Swift but XcodeGen is working well for me.

Included are set of linting tools I use to optimize my applications code. In this case I am currently using mint and a bash script to lint my code at each build:

Faire/StringsLint@0.1.7
nicklockwood/SwiftFormat@0.51.13
realm/SwiftLint@0.41.0

With XcodeGen, I have the option to set how strict my linting will be and can pass that into the Xcode build steps accordingly.

GitLab CI

I have been using GitLab for years on my private projects and have had very few issues with their CI setup. Purchasing a Mac mini for my CI has been a big advantage as well allowing me to regularly build and verify the builds of my applications.

With GitLab, I have been able to setup builds and testing on both macOS and Linux docker machines. The benefit of having targets separated really pays off on the Linux setup since much of my code-base isn’t built to be Apple-specific there I can test business logic quickly on Linux and then for higher priority build ensure they work on macOS.

So while I can’t test Observation or Virtualization, I can test the base OS-agnostic function on Linux as well as iPhone Simulator if a developer didn’t want to install a Sonoma beta during development.

Fastlane

Most importantly Fastlane was easily configured with the CI setup. At no point did I manually archive and upload to the App Store any builds. This meant all builds and metadata were deployed via Fastlane and Gitlab CI. Additionally match was used for storing and setting up certificates and provisioning profile making sharing the project much easier and worked really well with the XcodeGen setup. Lastly after every build was uploaded I used yq to increment the build number in the XcodeGen project file ensuring I’ll never upload the same build number again.

If a tree falls in the forest...

It's really great to see an automated system quickly verify and deploy a build to TestFlight or to the AppStore. However it means nothing if no one is using are testing the app. Let's discuss the marketing side, how AI fits in, and what's the future for Bushel.

I also learned my lesson trying to support Monterey. As a solo developer, it was not worth losing some many APIs for a possibly wider audience. I can begin to write an app for macOS Sonoma 14 in the summer and have plenty of time to be ready for the new OS.

• Part 1 - From Seed of an Idea
• Part 2 - Building the Crust
• Part 3 - Design, Architecture, and Automation
• Part 4 - Making Cider from Apples

• SwiftData
• SwiftUI
• Sandboxing
• Virtualization
  • New Snapshot API
  • Observation

SwiftData

SwiftData is a pretty decent API for maintaining a database of relational sets of data. Is it perfect? No. However it is what I’d expect from a first year API from Apple.

Honestly the biggest hurdle was the ever changing APIs as I went from one beta to the next - that’s something I should expect.

As I’ve stated with any new API, it’s wrapping my head around the way they (Apple) think a relational local database should be done. To some it’s what they expect from MySQL, Postgres, or SQLite. Having committed years of doing development in Vapor, my Swift database work was done with Fluent API.

Fluent is Vapor’s default framework for interfacing with a server database. The way they handled concepts such as relationships, Fluent and SwiftData were far apart. Additionally was the introduction of Swift Macros which creates even more complexity.

For instance the night before WWDC, I created a LivePreview structure. Then the following day after, I added the new LivePreview macro and my code would not compile. I was puzzled until I realized how Macros worked.

I have heard a lot of valid criticisms regarding SwiftData - all if not most valid. For me however I thought about long term support and where I wanted to invest my time. Pulling in a third party library was an option but one I wanted to avoid.

My biggest regret was not employing the use of ModelActors in Bushel.

Through my scouring of videos and documentation I found little on the topic and as SwiftData progressed through Xcode betas and integrated with SwiftUI I found the issue of threading and actors becoming more and more important. My hope is that I employ these throughout a future version of the App.

SwiftUI

With the decision to only support macOS Sonoma and up came the freedom to use the latest and greatest in SwiftUI APIs. For macOS this especially meant the use window management APIs as opposed to the messy way of handling windows via AppKit and URL hacks.

The biggest hurdle was tackling the issue with the Document-Based APIs. In the end, it became evident to ditch those for my own implementation. There were many reasons for this but the gains made through Apple’s API did not make sense compared to freedom I would get with my own implementation. The free APIs did not add many benefits for a system using such large and complex file types.

Looking back, I very confident this was the right decision. This meant a lot of AppKit hacks could be removed for managing window. However there were a few instances where I needed AppKit in order to customize or optimize the UI such as:

• custom NSOpenPanel and NSSavePanel
• improve Virtual Machine session window
• handling window state via NSWindowDelegate

//
// View+NSWindowDelegate.swift
// Copyright (c) 2023 BrightDigit.
//

#if canImport(AppKit) && canImport(SwiftUI)
  import AppKit
  import SwiftUI

  private struct NSWindowDelegateAdaptorModifier: ViewModifier {
    @Binding var binding: NSWindowDelegate?
    
    // swiftlint:disable:next weak_delegate
    let delegate: NSWindowDelegate

    init(
      binding: Binding<NSWindowDelegate?>,
      delegate: @autoclosure () -> NSWindowDelegate
    ) {
      self._binding = binding
      self.delegate = binding.wrappedValue ?? delegate()

      self.binding = self.delegate
    }

    func body(content: Content) -> some View {
      content.nsWindowAdaptor { window in
        assert(!self.delegate.isEqual(window?.delegate))
        assert(window != nil)
        window?.delegate = delegate
      }
    }
  }

  public extension View {
    func nsWindowDelegateAdaptor(
      _ binding: Binding<NSWindowDelegate?>,
      _ delegate: @autoclosure () -> NSWindowDelegate
    ) -> some View {
      self.modifier(
        NSWindowDelegateAdaptorModifier(
          binding: binding,
          delegate: delegate()
        )
      )
    }
  }
#endif

I am sure there are blind spots to the API however I am sure they are rare and easily fixable.

Sandboxing

I wanted to least amount of friction in deploying the app so the Mac App Store became the obvious choice for the immediate future. This meant I needed to work with Sandboxing in order to publish the app.

This means most of all working with file URL bookmarks. Since I was already employing SwiftData, that becomes the obvious place.

Bushel uses the rigorous system of using SwiftData to consistently gain and keep access to various files. Since we are using packaged directories, once we create a bookmark for the packaged directory, Virtualization will have proper access to all the components.

As previously stated, sandboxing is the reason a Library document type was created since it ensures Bushel will have consistent access to ipsw files inside a library.

Virtualization

The Virtualization framework is surprisingly not the most difficult part of the application. However there are a few challenges related to Virtualization, tracking state with SwiftUI, Restore Image support, and Snapshots.

New Snapshot API

Before the release of macOS Sonoma I did create snapshot feature using NSFileVersion, however with WWDC we were introduced to a new API for saving the machine state. With no longer supporting Monterey I figured this would be the ideal way to save the machine state. Unfortunately there is one major drawback, saving machine state is only supported for Virtual Machines with Sonoma installed.

For an app which is supposed to allow users to test their app on older operating systems, this is useless. This meant that unlike my work in UserDefaults & Combine or the old SwiftUI Window Management code, using NSFileVersion originally was a benefit. NSFileVersion has very little documentation and is mostly used along with iCloud. However it does its job. Unfortunately due to the nature of APFS and NSFileVersion, the biggest issue is the that I have no way in knowing how much each snapshot takes up in disk space. I was really looking forward to add SwiftUI Pie Chart showing the file space allocation but that’ll have to wait for now.

Another issue is that certain restore images are simply not supported. Either the version is too old which is the case for anything before macOS 12.0.1 or Apple know longer allows using the image. My guess is that this is purposeful on Apple’s part due to security updates. While I can’t work around this, I can at least communicate that clearly to the user for now.

Much of the Virtualization framework is built on top of Objective-C based code, which means it isn’t using a method friendly to SwiftUI. Therefore I needed to listen to changes to the virtual machine either via the Delegate pattern or Key Value Changed.

//
// KVObservation.swift
// Copyright (c) 2023 BrightDigit.
//

#if canImport(ObjectiveC)
  import Foundation

  public protocol KVObservation: AnyObject {}

  extension NSObject {
    public static func getAllPropertyKeys() -> [String] {
      Self.getAllPropertyKeys(of: Self.self)
    }

    private static func getAllPropertyKeys<ClassType: AnyObject>(of _: ClassType.Type) -> [String] {
      let classType: AnyClass = ClassType.self
      return self.getAllPropertyKeys(of: classType)
    }

    private static func getAllPropertyKeys(of classType: AnyClass) -> [String] {
      var count: UInt32 = 0
      let properties = class_copyPropertyList(classType, &count)
      var propertyKeys: [String] = []

      for index in 0 ..< Int(count) {
        if
          let property = properties?[index],
          let propertyName = String(utf8String: property_getName(property)) {
          propertyKeys.append(propertyName)
        }
      }

      free(properties)
      return propertyKeys
    }

    public func addObserver(
      _ observer: NSObject,
      options: NSKeyValueObservingOptions,
      _ isIncluded: @escaping (String) -> Bool = { _ in true }
    ) -> KVObservation {
      let propertyKeys = self.getAllPropertyKeys().filter(isIncluded)
      return self.addObserver(observer, forKeyPaths: propertyKeys, options: options)
    }

    private func addObserver(
      _ observer: NSObject,
      forKeyPaths keyPaths: [String],
      options: NSKeyValueObservingOptions
    ) -> KVObservation {
      for keyPath in keyPaths {
        self.addObserver(observer, forKeyPath: keyPath, options: options, context: nil)
      }

      return KVNSObservation(observed: self, observer: observer, keyPaths: keyPaths)
    }

    private func getAllPropertyKeys() -> [String] {
      let classType: AnyClass = type(of: self)

      return Self.getAllPropertyKeys(of: classType)
    }
  }
#endif

On top of this was built a class which would monitor changes and update properties accordingly for SwiftUI consumption. The choice for me was what kind of observing would I do.

Observation

As a big fan of Combine’s react pattern, I had used Combine through much of the application to react to changes in a model. However I could see some drawbacks:

• complex functional programming produced confusing code
• testing can become overwrought and difficult
• maintenance becomes challenging as designed behavior changes.

With WWDC2023, I had the opportunity to pivot to the new Observation framework. I was willing to give it shot since I knew Apple was investing in it and I was already redoing much of the underlying SwiftUI anyways. There were major benefits to the switch:

• Natively supported with SwiftData
• Simpler tracking of changes and updates
• Easier separation of logic and properties

Throughout the app, Observation is used. For every View, there’s an Observable Object tired to it which contains nearly all the properties used by the object. Rather than using withObservationTracking which I found misleading I used didSet which felt incorrect but the lack of documentation and the simplicity of its functionality worked perfectly with the application.

With using the new WindowGroup API, I used a patten throughout the app which the View would listen to changes to the @Binding object passed to it and let the Observation object know.

//
// DocumentView.swift
// Copyright (c) 2023 BrightDigit.
//

#if canImport(SwiftUI)
  import BushelCore
  import BushelLocalization
  import BushelLogging
  import BushelMachine
  import BushelMachineEnvironment
  import SwiftUI

  struct DocumentView: View, Loggable {
    @State var object = DocumentObject()
    @Binding var machineFile: MachineFile?

    var body: some View {
      TabView {
        DetailsView(machineObject: object.machineObject)
          .tabItem {
            Label(LocalizedStringID.machineDetailsSystemTab, systemImage: "list.bullet.rectangle.fill")
          }
        #if os(macOS)
          SnapshotsView(url: object.url, machineObject: object.machineObject).tabItem {
            Label("Snapshots", systemImage: "camera")
          }
        #endif
      }
      .onAppear {
        self.beginLoadingURL(machineFile?.url)
      }
      .onChange(of: self.machineFile?.url) {
        self.beginLoadingURL($1)
      }
    }

    func beginLoadingURL(_ url: URL?) {
      self.object
        .beginLoadingURL(
          url,
          withContext: context,
          restoreImageDBfrom: machineRestoreImageDBFrom.callAsFunction(_:),
          snapshotFactory: snapshotProvider,
          using: systemManager,
          metadataLabelProvider.callAsFunction(_:_:)
        )
    }
  }
#endif

There were also some common developer tools and optimization I made in my build and deployment process as well.

However I did start to miss some of the benefits of the iOS simulator:

• The ability to easily start with a brand new iPhone every time.
• To test different versions of the operating system.

I did not have these benefits as a macOS developer.

When I’d develop a Mac app and a user would notify me of a bug, I had no way to test it - and replicate their environment.

• Part 1 - From Seed of an Idea
• Part 2 - Building the Crust
• Part 3 - Design, Architecture, and Automation
• Part 4 - Making Cider from Apples

• Getting Started
• What am I doing?
• Designing around a sandbox
• Document Based?

For instance, when I forgot the different ways decimal points are used and assumed one particular way. I didn’t have an easy way at the time to test my app using that localization. Another instance is when a developer setup script needs to be created. How do I test when the developer doesn’t have Homebrew, Git, or Xcode installed and deal with those scenarios?

Besides that, the iOS simulator has a solid set of tools with simctl as well as more powerful dev tools like RocketSim by Antoine van der Lee.

There’s apps like VirtualBox and Parallels however those app aren’t targeted to Mac developers like myself. I wanted something to have that Apple feel while being a powerful developer tool.

Unfortunately creating my own VM app seemed like a huge undertaking, how would I even get started?

Getting Started

There had been the Hypervisor framework for quite some time however it’s a C-based API and lacks the Swift-ness I had grown accustomed to. However in 2020, Apple released the Virtualization framework which gave developers a Swift interface for creating and running their own macOS VMs.

This meant I can at least try to create an VM app for macOS Developers.

Apple has a great sample project which shows you how to easily setup a new VM. The challenges will be creating a new Sandboxed app which integrates SwiftUI with the Virtualization framework.

Starting the summer of 2022, I began work on designing Bushel. How can I create an intuitive yet functional app for developers?

What am I doing?

The biggest challenge came from using SwiftUI and being able to keep record of existing images and machines. The Virtualization framework uses restore images as the basis for setting up (i.e. installing the OS for) a brand new virtual machine. If you’ve ever had to restore an iOS device, you probably are familiar with these ipsw files. Since the advent of Apple Silicon Macs, this has followed that same pattern.

I did not want to employ Core Data since I didn't want to maintain something with a technology which was nearing a Swift-y refresh. I also wanted to take advantage of the latest APIs in SwiftUI while supporting the oldest OS I can. The result was using UserDefaults to store records about the machines and images used while supporting macOS Monterey 12 and up.

This would be become a challenge going forward with some serious lessons learned.

Designing around a sandbox

Firstly with a sandboxed app I need a way to keep record of bookmarks for each file uses. I also wanted to take advantage of the new Document-Based capabilities in SwiftUI.

Inspired by the work I do Final Cut Pro, I created a Library for restore images. This would contain the easily accessible metadata for each image while also ensuring it was a file accessible by Bushel. In most cases, users would only need one Library on their host machine but supporting multiple wouldn’t hurt either. Since these images were between 12-15 GB I wanted to allow users to specify where they were located on their disk as opposed to storing them inside the app’s configuration.

Document-Based?

Despite using the latest technologies, the Document-Based SwiftUI API ended up becoming more hinderance rather than a benefit. The Document-Based SwiftUI API was more tailored for smaller files of which the developer had greater control over. In the case of BushelLibraries and more so Machines, there are components which are very large but more so I only had control over through the Virtualization framework. These are files like the virtual machine identifier, virtual machine disk and more. Additionally maintaining records of created machines and libraries in UserDefaults along with Combine became a mess.

Lastly supporting Monterey meant I lost a lot of the new APIs available to me regarding window management in macOS. macOS SwiftUI has been less of a priority for Apple and so I was creating even more challenges for myself by supporting an older OS.

As more work came in Busheltook a back seat. However with WWDC came new opportunities for a serious refresh of Bushel.

One of the most common questions I get is, how do I become a developer in two months? And it's… no, you have the wrong attitude already.

Sean Allen is an established iOS developer known for his courses and educational content on his website and YouTube. Earlier this year, I talked with Sean Allen on EmpowerApps, and this was how he started our conversation on misconceptions about how to become an iOS developer.

If you’re a new iOS or Swift developer or studying to become one, this is for you. This article busts some of the biggest myths out there about becoming a developer with the best tips Sean and I discussed on how to succeed as a professional.

How long does it take to become a good iOS developer?

Longer than you think. And a lot longer than two months.

Good software development of any kind heavily relies on experiential learning – you need to make software and a lot of it. You need to do the same things – solving similar problems and developing similar functionality over and over again to gain the skills and memory to excel in this profession.

It also never stops – you’ll never stop needing to learn new things as a developer. Continuous learning is essential to staying relevant and on the leading edge of any development you want to do. With iOS and Swift, we’re often carefully listening for any signals Apple gives us that show what direction it wants to guide its ecosystem, particularly during WWDC.

It will be a long, difficult process – there really isn’t any way around that. If it were easy, we probably wouldn’t make any money doing it. At the time of writing, the average salary of an iOS developer in the United States is $134,000, reliably putting them in the top 15% of income earners in the country.

The Tutorial Trap

You watch a tutorial to learn how to build a specific function. A week later, when you’re trying to develop that same function, you suddenly find yourself straining to remember how to do it.

I should know this.

It is a myth, one that we tell ourselves more than anything else, that just because we know what code to write doesn’t mean we know the code.

Sean calls this The Tutorial Trap. He may have even coined the term. But it’s a phenomenon that experienced developers are all too familiar with. A tutorial often only gives you a surface-level knowledge of the code, but there’s more going on, and there will always be more you discover is going on the deeper you go.

As I mentioned above, there’s always something new coming out. At BrightDigit, we’re always trying to stay on top of that and share what we know about different platforms, whether it’s the evolution of WatchOS or SwiftUI’s impact on how we build apps.

As with many things, the real test of what you learn is when you have to create something new. As Sean put it:

... my learning skyrocketed when I decided to make my own project, and there was no cookie cutter recipe to follow.

You’ll likely find that tutorials are most helpful for filling gaps in your knowledge when trying to learn something new. And it may, for a time, feel like you’re banging your head against a wall. However, you are using an established mechanism of educational psychology, where building knowledge does eventually lead to unlocks in your understanding and comprehension of that same information. In our chat, Sean described it as two levers being pulled., but it’s sometimes a bit more complex than that. I did a breakdown of what this process looks like in the context of learning new APIs, which includes more specific suggestions that can help you.
> youtube https://youtu.be/gH3QnVHsUAc

What does it take to be a professional iOS developer?

If you got this far, knowing how hard it will be to develop professional development skills, and you’re still excited and welcome the challenge, I have good news: you probably have the personality traits that will make you a great developer.

Obstacles in software programming never go away – the people who succeed are those with the temperament and patience to keep at it until they find a way through. That’s essentially what this job is all about.

On Soft Skills

Sean is a believer in soft skills, reckoning when it comes to developing skills that will serve you well in this field, it should be about a 50/50 split between the hard technical skills and soft communication skills. And I agree with him.

I’ve written previously on both supporting good communication as a team manager and why you should be looking for those same skills in the hiring process. For a lot of iOS development, unless you’re doing something incredibly technical, your ability to work well with team members, stakeholders, and customers will hugely influence your career.

If you’re interested in learning more, you can also listen to my chat with Kim Arnett, where we talk about communication skills and what to look for as both the interviewee and interviewer for development jobs. And while it’s been a few years, Paul Hudson’s chat about upgrading your skills is still very relevant for anyone just starting out with iOS.

Decide how you want to have an impact

When choosing where you want to go with iOS development, there are really two main paths you can take.

One is to go to work for a mega-corporation (think Facebook, Amazon,Google, and Apple itself) or another large company. This path usually comes with lots of perks and benefits, lots of structure to your work, not to mention you will be surrounded by tons of other developers who can help you and bounce ideas off of. The downside is that you might be one of thousands of developers, the hours tend to be very long, and you might not feel like you’re contributing all that much.

The other, which is more common if you're a self-taught developer, is to start your career at a small company or startup. You might be the only iOS developer in the organization, but it also means that everything you do has an immediate and significant impact on the business. Pay may be a little lower, especially if you work for a startup, but you also usually have a lot of control and autonomy over how you work (although hours may still be long).

Both Sean and I fall into this category, so we have some bias. Sean has a great suggestion if you choose to go small, to learn how to show off your portfolio to demonstrate how you work – while you’ll also still need a resume, a working portfolio is where you can show what you’re really capable of.

One path is not better than the other, but it often comes down to what you personally want and need.

Always be networking

Regardless of your path, if you’re committed to being part of the iOS development community, we recommend you network, both online and in person.

While it’s not quite what it used to be, X (formerly Twitter) is still the social media platform where you can find the highest concentrations of iOS and Swift developers sharing their thoughts, ideas, and what they’re working on. LinkedIn and Mastodon are good places if you’re looking for more experienced or senior developers, but at the time of writing this isn't a trend yet.

If you can, we recommend doing local, in-person networking if you live near a tech hub. In the US, this would include San Francisco, Seattle, Austin, New York, Boston, or Raleigh. There still isn’t anything that’s a true substitute for time spent in person chatting and having a good time with your peers.

For more ideas, check out my guide on networking related to WWDC for Swift developers.

Thanks to Sean Allen

Thanks again to Sean Allen for the great conversation we had on the podcast. If you haven’t had a chance yet, go give it a listen for a more complete discussion about the ideas I’ve written about here. I also suggest following Sean on YouTube and check out some of his videos.

If you liked this, subscribe to our YouTube channel too!

All episodes of the EmpowerApps podcast are published on YouTube through the BrightDigit channel, where I interview other iOS developers and other people shaping how we do iOS and Swift development around the world.

But humane code takes this further. It considers the everyday struggles and limitations that we all experience and the ways that our brains can, on some days, be really hard to use. When considering these realities, we choose to have empathy and kindness for other developers and ourselves.

This article is for senior developers, team leads, and managers who are invested in more deeply supporting their developers. Humane code is also an excellent tool for leaders who want to maintain good morale and employee retention.

I am covering what humane code is, its benefits, and good habits and practices for creating an environment that best supports developing it.

What is Humane Code?

Humane code appears to have been first coined by Danish-based software architect Mark Seemann in his book Code That Fits In Your Head. The book is essentially a guide to reducing code complexity and building software at a sustainable, human pace.

At its core, humane code is based on the idea that code is a conversation. This conversation is between you as the developer writing it, a future version of yourself who will need to review and explain it, and other developers who will need to use and maintain what you create.

Ensuring that your code is readable means ensuring it communicates what is needed and expected by people in the future. It’s also a guide to avoiding the pitfall of fixating on the cleverest solution to our present challenges if that solution isn’t easy to explain. If it can’t be communicated straightforwardly, it’s probably not sustainable.

Why is Humane Code Important?

As developers, we often try too hard to write code that works quickly or shows off cool features or optimization we’re excited about – I’m guilty of this, too. 😁 It looks impressive and wows managers and senior executives when you first demo it.

The problem is that those same managers and executives will also be stressing out years later when they realize what a pain it is to work with when bugs need to be fixed, features need to be added, or maintenance needs to be done on the codebase.

Code that is easy to maintain and understand is ultimately more profitable and delivers long-term value to a company.

Good Habits for Creating Humane Code

Make sure things are broken down appropriately

Having long, complex functions in our code isn’t necessarily bad, but as a general rule, the longer the function, the less readable it is.

The main reason this is so is because of the limitations of the human brain, particularly our short-term working memory.

You probably recognize that when we’re coding a specific function, we usually have a list of things that you need to hold in your head while you’re working on it – acceptance criteria, relevant dependencies, and a vision of what we want the code to look like when it’s complete. This is opposed to long-term memory, which is more akin to the habits, practices and things we’ve learned from years of programming.

And there is a limit to how much you can hold in your brain at any time. Seemann, in his book, cites that we can hold anywhere from 4-7 bits of information in our minds at once, but that heavily depends on what condition our mind is in that day.

It also fluctuates depending on how much attention and focus we have available. Anything that distracts you reduces this, as well as various factors related to our well-being, including whether:

• you had enough sleep last night
• you are hungry or thirsty
• the chair and desk you’re using are comfortable
• the room temperature is comfortable

And even more abstract things like if you have harmony within your relationships with team members or family.

All this to say, if any of these things are dragging on our attention, it translates into how we work with code and how much we need to hold in our minds to get into it and understand it enough to achieve whatever we’re on. This means that even under optimal conditions, having to pause and parse old code to understand will usually cause us to lose the context we have for the new feature we’re working on.

A good starting point is to break types down, including making each type and extension in the code its own separate file, and each file shouldn't be so long that it’s hard to hold its entire context in your mind. It is also a good idea to ensure consistent style and formatting throughout your entire code base – tools like SwiftLint and SwiftFormat can help you by automating and enforcing the conventions you create.

Related to this are the concepts of microapps architecture, TDD with Swift and good principles of iOS and Swift architecture, which offer their own complementary ideas and concepts.

Use descriptive naming and comments

When naming your databases, methods and classes, take a little time to consider calling them something descriptive so that you can be confident your future self or another person will understand what it is.

And while some argue that good code doesn’t require comments, if we’re being realistic, that will be the case when we’re 100% on top of our game. But few of our work days are that perfect – most days, we usually have something that’s drawing away our attention, making perfection an unreasonably high bar to clear day in and day out.

While comments may not be needed, they can be really helpful for adding context to your code when they’re done thoughtfully and without creating too much ‘noise.’ Take advantage of Swift’s DocC native comment system. It’s easy to use, looks great, and ensures future developers can understand.

Code reviews

The code review process is an essential part of humane development. It guarantees that somebody is looking at your code without the context that you had when you developed a feature and asking the questions needed to understand it.

It’s a great way to combat the problem of being “too close” to the code you’ve written. After enough time, you often can’t see obvious errors or missing context because, over time, you naturally become blind to these details because they were embedded into the way you thought about the code as you were writing.

Make your code accessible

Traditionally, when we’re talking about accessible code, we’re usually thinking about the end user and their limitations. But accessible code also includes making sure your code is accessible to other developers.

As we covered earlier, our working memory is highly susceptible to our environment and general mood – sleep, food, or even if we’re just a bit grumpy one day, it can mean our neurons aren’t firing as well as they could be.

But there’s also a range of more long-lasting conditions that someone can experience or live with that make working with code even harder. These range from executive function disorders like ADHD, autism and OCD; learning disorders like dyslexia and dyscalculia; to physical limitations and disabilities, including blindness, deafness, and living without the use of a limb or having complete motor control.

Accessibility is ultimately about recognizing that humans and their brains are imperfect, and because of that, making it as easy to understand as possible and ensuring your code is not more cognitively taxing than needed.

This can be hard, especially if these limitations are not part of your own day-to-day life, but it can be figured out early if you make a point of asking questions at the system design stage of app development.

Keep Your Logic Simple with Cyclomatic Complexity

We covered above how useful it is to keep functions small; there’s an additional element to keep in mind on the path of humane development – limiting cyclomatic complexity.

Despite its name, cyclomatic complexity is pretty easy to understand – it measures all the paths you can take through a piece of code with a given function. The higher the cyclomatic complexity, the more paths there are and the more decisions that need to be made.

Jill Scott on EmpowerApps does a great job explaining this, and I agree that’s an excellent way to measure to tell where you might want to look to simplify your logic. However, as Jill points out, it’s not perfect – a high complexity-rated piece of code might still be readable and accessible.

A Special Thanks to Jill Scott

A big thank you to Jill Scott for sharing her insights in my conversation with her on EmpowerApps. Our discussion was foundational in helping me learn more about the concept of humane code and developing this article. If you haven’t already, I encourage you to listen, following Jill over on X (formerly Twitter) at @Jilsco9.

Announced at WWDC 2023, with the full release expected in September, watchOS 10 comes loaded with massive changes that will fundamentally shift how we make apps for the Apple Watch.

We’re covering what the future of the Apple Watch likely holds and what the most important features to look for from Apple and watchOS 10.

What is the future of Apple Watch apps?

Since the widespread adoption of Swift UI in 2020, developing apps for the Apple Watch has become significantly more manageable and enjoyable. With the new OS, we potentially see the end of the biggest barrier to creating complex, cost-effective Apple Watch apps, especially ‘watch-first’ apps.

Before now, Apple Watch apps have suffered from hardware limitations and a lack of consumer awareness about what’s available. At BrightDigit, we’ve been optimistic about the Apple Watch’s trajectory: first with the health-related functionality first shipped with the Series 4; the leaps and bounds made with the introduction of watchOS 6 and the Series 5, and particularly with the ability to build complications with SwiftUI in watchOS 7.

Battery limitations remain baked into how the Apple Watch runs – even after the introduction of low-power mode with watchOS 9 – causing your apps to lose network connectivity or shut down because they are suddenly ‘not doing anything.’

And while Apple has gained the largest share of the smartwatch market, it has been a relatively slow-growing part of the Apple App ecosystem, and most watch users are only using a minimal range of apps.

watchOS 10 is the first major release that could change that, but work still needs to be done by the release of the Apple Watch Series 9 if that’s going to be realistic.

One of the biggest obstacles to this is that, at the time of writing, the App Store isn’t well-optimized for Apple Watch apps. They have recently added a dedicated Apple Watch apps category within the App Store, but it’s challenging to use on the Apple Watch itself and buried right at the bottom of the page when looking for it on the iPhone. The result is difficulty in new Apple Watch apps getting noticed by users.

What makes watchOS 10 different?

There are several changes that we can already see in watchOS 10’s beta release that amount to a major step in terms of usability and opportunities for Swift developers:

Full Navigation

The watchOS 10 beta is showing some significant changes to user navigation. This includes new features like a vertical tap view, lists that are easy to scroll through, and a toolbar.

Getting these right will be critical if Apple is serious about growing its market for the Apple Watch and encouraging existing users to buy the latest hardware.

Assuming Apple understands this perfectly well, we can look forward to these major improvements in user experience being included in the launch of watchOS 10. In turn this makes it far easier and attractive for independent developers and brands to create dedicated Apple Watch apps.

A More Glanceable Interface

This is perhaps the one change that everyone can get excited about. watchOS 10 is seeing a complete overhaul of the user interface, with a new grid-like design and focus on making it easy to get the information you want at a glance from various widgets.

Smart Stack

Related to the new interface is the addition of a library of the most used/most important widgets, making it easy to create new interfaces quickly for simple Apple Watch apps.

This works similarly to the widget stack available on iOS and the Siri watch face, except now the entire library is accessible at all times from the watch face. It also learns, offering up certain widgets first based on your user behavior.

Improved Debugging

Debugging on the Apple Watch up until now has been complicated and unreliable. With watchOS 10, it has improved enormously, making it uncomplicated when developing and testing new apps for the Watch.

And Several more minor but still great improvements, including

• NFC interactions between the Apple Watch and the iPhone
• Offline maps
• New APIs for velocity and acceleration data
• Bluetooth compatibility between the Apple Watch and popular digital cycling tools
• For travelers moving outside their reception areas, the Apple Watch now shows a waypoint marking where the user last had connectivity.
• A new Snoopy-themed watch face!

A special thank you to fellow SwiftUI developer and product designer Hidde van der Ploeg. I’ve chatted with Hidde on EmpowerApps, and he and I had a great conversation, sharing our excitement for watchOS 10 and the possibilities it could open up for us as developers.

At BrightDigit, we’re already invested in building apps primarily for the Apple Watch. Most prominent of these are Heartwitch and gBeat, which make use of the Watch’s health functionality for streamers and fitness trainers, respectively. We’ve also got more plans in store, which you can learn about here.

If you want a Watch app, let’s talk!

I offer specialized Swift development consulting for organizations and agencies that want to build high-quality apps for the Apple ecosystem. If you’re looking for additional expertise or are planning to start developing a new Swift app this year, let’s talk. You can book a 30-minute consulting call with me right now and find out how I can help you.

If you’re leading or managing the development and growth of large, complex apps, this article is meant to help you understand the benefits, both business and technical, of microapp architecture and how to decide whether it might be a good choice for your development needs.

What is microapp architecture?

Microapp architecture is the style of using smaller single-function apps to create larger, more complex apps.

The main principle is rather than building a single, large, monolithic app, you break down the functionality you need into small, lightweight, self-contained modules and then assemble them as a larger app. Microapps are a way of organizing the functionality of your app and its related services.

There’s also another term you’ll see related to this: microservices. You can think of microservices as the same style of architecture but applied to the development of the backend of your app, while microapps usually mean we’re talking about your app’s frontend and UI.

As we’re mostly interested in microapps for apps in the iOS ecosystem, we’re going to be primarily focusing on how to use this style in Swift for mobile applications, but the principles of microapp architecture can be used for just about any platform or programming language.

What are microapps good for?

With apps I’ve developed for both my clients and myself, I have come to really like using microapps. My apps have gotten pretty large – microapps have been a great way to make the codebases easier to maintain, change, and add new functionality to.

Build, test and change your app’s functionality quickly

The biggest and most obvious benefit of microapps is that when your entire app is broken down into single-function parts, building each part, testing it, and adjusting it as needed can be done very rapidly.

This is a bonus if you’re already using short development cycles or sprints as part of using frameworks like Scrum, Kanban, or a continuous integration approach to development. Using microapps architecture should mean both minimal compile-time needed for everything and minimal operational and merge conflicts, as modules are independent of each other.

This also makes microapp architecture a good choice if you’re developing an app that:

• Requires a lot of small, discrete tasks embedded in the UI.
• You plan to scale or add lots of additional functionality over its lifecycle.

Do One Thing Really Really Well

If you’re going to take full advantage of having fine control over each function within your app’s UI, microapps make it possible to tailor each module to your users’ needs and overall make your user experience (UX) to best it can possibly be once the entire app is assembled.

Essentially, the app your user sees wraps around all the microapp modules, bringing everything together into a single, coherent UX. Ideally, you’re using some kind of UI design system, but even if you’re not, you should have a dedicated library to make it easy to import modules and maintain a consistent look and feel across all your microapps.

On large multi-team projects, this style can also be used for building internal tools that are made for them, built only for working on a specific feature or component.

For iOS specifically, using Swift Package Manager is a great tool for using microapp architecture, as it easily allows you to modularize all your app’s functionality.

Keep it all internal

Microapp architecture, because of its modularity, allows you to bring better API design to your development projects. This approach is essentially designed to remove the need for inter-team dependencies.

You should be able to deliver even single modules to quality assurance, who are able to verify a given feature works and meets requirements without the need to wait for other teams to finish the development of a given module.

What are the challenges of implementing microapps?

While microapp architecture is an excellent choice for an enormous number of complex apps, they are not a panacea. There are a few contexts where it may not be the best approach or where you’ll only get to realize a small amount of its potential:

Difficult to integrate with existing systems

Microapp architecture, in a way, assumes that either you’re developing a new greenfield app or you’re ready and willing to rethink completely how your developers approach complex app development and who has control and ownership of the app’s features.

On a business level, microapp architecture gives each development team complete ownership of the modules they’re working on, independent of other parts of the business. It is assumed that the business, as an organization, is ready to give its teams that kind of autonomy.

Because everything is broken down into small parts, this approach will likely make it hard to use existing systems that aren’t designed this way. On a technical level, microapp architecture doesn’t mean “the same app we had before, but now split up into 20 different modules,” but an approach that helps you refine and focus on a set of features being the most user-friendly they can be.

Specific Use Case instead of All-Purpose

If you’re trying to stuff all your existing offerings into a single app, microapp architecture won’t save your falling user adoption rate – it will only help you run into the same obstacle faster. Undertaking a redevelopment of a large, complex app using microapps requires proper planning, training and management of the development process to handle it.

Because microapp architecture is built around breaking things down into either single-function modules or modules with a limited number of related functions, it is an excellent solution to build around specific use cases.

What it is not great at is handling a wide array of unrelated purposes, where you end up with a ton of modules that are only going to be used for one thing, which kind of defeats the efficiencies this approach is designed to give you.

How small is too small?

If you’ve got this far, you might think you should break every function or set of functions down into its own module. While it’s great to decouple things, it can add extra complexity to your project. While there isn’t a hard rule for this, some things probably don’t need to be completely modularized. Given that the development team has ownership of each module, it’s best to make sure there is a conversation within the team about how they’re doing to split and extract all the functionality they need to deliver.

How to figure out if microapps are a good choice for you

To sum things up, if you’re still wondering where a microapp approach would be a big help in your development process, there are a few questions you can ask yourself and your team – if you can answer ‘yes’ to most of them, then it’s likely a good choice;

1. Do you know what specific user challenges you want to solve that fit the strengths of microapp architecture – i.e. can you break it down into related functional modules?
2. Are you and your client prepared for short development cycles? Do all stakeholders have realistic expectations about what that’s going to look like?
3. How much do you need task-specific applications?
4. Is it important for you to constantly be able to modify your app? If you don’t think your app will change much after full release, microapps may be less helpful.
5. Does the app match business objectives, not just the needs of the development team?

Special Thanks to Majid Jabrayilov and Gio Lodi

I want to give a big thank you to Majid, who I recently had back on EmpowerApps. Talking with him was an inspiration and guide in putting this article together. He has some excellent content on his website about how to use microapps with Swift, which is a great resource if you’re looking to get started. I’d also like to thank Gio Lodi, who wrote an excellent introduction to microapps for developers if you’re interested.

In a way, it’s like Christmas for Swift development – WWDC sets the tone for the following 12 months, what it wants us to focus on, and let us know what Apple thinks is most valuable for the billion or so users of its products.

Apple tends to run the conference with the assumption that everyone attending is up to date on where its software is right now. Watching the WWDC talks is often the only way to understand how the newest things work or even how to make them work.

If you’re new to Apple and Swift development, it can be overwhelming with the enormous amount of information delivered over a week.

This year, 2023, for example, we are looking forward to the release of iOS/iPadOS 17, tvOS 17, macOS 14, and watchOS 10, with the expectation that we’ll see some major usability and quality-of-life improvements. Additionally, we’re expecting an announcement of an augmented/virtual reality headset – a treat for WWDC, which is rarely used to showcase hardware (that doesn’t usually happen until the fall).

I recently enjoyed chatting with Peter Witham, a fellow developer and the mind behind the Swift-learning site, CompileSwift, on EmpowerApps. We discussed WWDC and how to get the most out of the conference. This is a roundup of some of the best tips he and I talked about on the podcast.

Back Up Everything

If you plan to try out beta OS versions or anything new with Xcode on your Mac, it is worth going to the trouble of cloning your drives to an external and ensuring you can boot from it before trying anything.

The approach of WWDC each year should signal all Swift developers to back up everything on all their machines if they haven’t already.

There will be interesting and potentially exciting things you can try out that are still in some kind of pre-release state. On the one hand, it’s an opportunity for developers to help Apple identify and fix quality and usability issues. But they historically also contain errors that can render other software on your machine unusable – or it might outright delete all your data.

Use TimeMachine or another cloud service back up to a local drive, but don’t skip this.

Then, if you have the time, create an additional partition on your internal drive with another backup. You may end up thanking yourself later.

Apple explicitly recommends this on its beta software support page, saying to only install “ on devices and systems that you’re prepared to erase if necessary.”

Don’t Install Betas On Your iPhone or Apple Watch (if you don’t have a spare device)

Related to the above, if you plan on installing a beta OS on any machine, especially iPhones and Watches, be prepared for that device to become useless.

During WWDC, iOS betas are likely to be very unstable, with major bugs. While it’s possible to opt out and roll back a particularly buggy beta, it is time-consuming to go through the process. And If you made the mistake of only backing up after running the beta, you won’t be able to restore it.

The same applies to the Apple Watch, although, given the pairing requirement, this is complicated (and expensive). The good news is it’s believed this will be improved with WatchOS 10, making it possible to pair the Watch with multiple and any Apple devices in the future.

Make a Viewing List

There’s usually so much that comes out during WWDC that it’s unrealistic to dive deep into everything. Instead, it is time to clear your WWDC bookmarks in the Apple Developer app and decide what is most important or exciting for you. It is worth it to be picky about what you watch or listen to.

Peter Witham suggests making notes for yourself for topics and sessions that grab your attention. He further suggests that the first time you watch a session, don’t worry about taking exhaustive notes – watch it all the way through and enjoy it. Then, if you’re still engaged by the time you get to the end, he recommends going back through it again and only then taking down the details.

As a general rule, when it comes to deciding what talks you should listen to, use the following criteria, which should ensure your time is spent efficiently:

• What you’re interested in
• Things that your current apps could use
• Features that you think you can build on top of

Additionally, the business and design talks during WWDC are often full of insights into what Apple is looking for when they think about what makes a successful app in the App Store.

Take note of any patterns you see in the talks. For example, if you see a lot of talks on a specific API. That’s usually a sign to pay attention and consider using it in your apps if it makes good business sense and you’re interested in being featured in the Store when the new API is fully released.

…and a list of questions

If you are fortunate enough to either attend one of the sessions to meet one of Apple’s engineers, or get to book a 1-on-1 lab session with one of them, be sure to come prepared with questions on their Developer app, as you have will have precious little time to come up with questions on the spot.

Resources to keep up to date and connect with the Swift development community

There are a ton of good resources available for Swift and iOS developers looking to prepare themselves for WWDC – content and news you can check out that studies what Apple is likely to come out with, as well as a number of online communities where you can chat with developers in our community to analyze what Apple releases and share ideas.

Hacking With Swift

Paul Hudson does a stellar job covering topics and news at the forefront of Swift app development. He recently published an article covering the release of Swift 5.8 with excellent breakdowns, code examples, and insights into what it could mean for the future of development.

WWDC 2023 Discord

A Discord server has already been set up for this year’s WWDC, and hundreds of Swift developers are already connecting and planning out what activities and talks they’re attending (both in person and online). WWDC is probably the biggest event of the year for bringing us developers together, so if your goal is to connect with people just like you, this is a great place to start.

Dub Dub Together

A live-streaming service where you can watch the keynote and other talks live online, with a live chat so you can talk to other viewers while things are happening.

WWDC Notes

WWDC Notes is a community initiative that collects notes for all of Apple’s WWDC videos. You can use this fantastic resource to check recaps of different talks, compressing what is usually hundreds of hours of recording into something manageable.

Additionally, Apple itself keeps its WWDC videos published for only about three years. WWDC Notes keeps everything as a repository if you ever want to go back and watch older talks.

It should be pointed out that WWDC Notes is only as good as its contributors. If you find yourself motivated to take thorough notes of a talk, you can publish them here for the benefit of other developers.

iOS Dev Happy Hour

If you can’t make it to WWDC or any other conferences to share experiences, hang out, and have a drink with other developers, iOS Dev Happy Hour gives you a chance to do it virtually instead.

MacRumors

MacRumors is usually a great resource for keeping up with the latest Swift developments, plus regular articles that explore and speculate what is coming next from Apple. At the time of writing, they’ve just published a thorough roundup ahead of WWDC, with a breakdown of what we can expect Apple will announce during this year’s conference.

If you are interested in more resources be sure to check out Apple's Beyond WWDC list here.

Lastly, Pace Yourself

WWDC is a week-long conference that marks the beginning of the next year of development in the Apple development community. You don’t have to be completely prepared, even on the day the conference starts. And pacing yourself applies equally if you are lucky to attend WWDC live or watch it all remotely.

What’s more, everything is recorded, so everything will be around for a while. The best advice is to take in the conference in a way that is best for the way you like to learn, whether that’s to sit and watch or immediately crack open Xcode and start playing around with things.

A quick search shows that the term is often associated with questions in developer job interviews, seeing how a candidate considers the design and architecture of the apps they make.

This definition is meant to capture not only what you need to know in an interview but how to use it as a cornerstone of great software development.

I was inspired to write about this after recently chatting with Tjeerd in 't Veen on the EmpowerApps podcast. Tjeerd is a fellow Swift developer and the author of Swift in Depth and an upcoming book called Mobile System Design. Tjeerd generously gave me a peak at the book, and I think we should all be excited.

Tjeerd’s goal for his new book is to help developers and engineers make better mobile apps by using design-level techniques and changing how we think about the code we make.

In our chat, Tjeerd shared a few powerful ideas that can be hugely helpful for mobile developers of all kinds, especially those working with iOS and Swift. This is an introduction to mobile system design, some of those ideas – why it’s such a powerful concept and how it, and Tjeerd’s book, can help you deliver better code faster.

System Design is about asking questions

When you think of the more general concept of system design in software development, it’s common to associate it with backend development – how the software’s architecture, components and data for an application are designed and work together to meet user requirements.

But this definition is incomplete. It glosses over the thousands of little decisions made by both developer and customer that go into making software features. As developers, we all create software, but how we approach this task can vary enormously.

So how do you capture all of those decisions in the system design of your app?

In our conversation, Tjeerd broke down the process of finding and defining these decisions using a few key concepts: one of which is asking the right questions.

I think the real power… is to really dive deep because if you ask the right questions, you can maybe even skip a couple sprints of work…

You can see this kind of questioning with the concepts of known knowns, known unknowns and unknown unknowns.

These were popularized by an infamous quote by former Secretary of Defense Donald Rumsfeld, but the idea is based on a much older psychology technique called a Johari Window. It is a useful idea for mapping out and becoming aware of the thousands of decisions and connections when building an app:

• Decisions you can figure out right at the start of development (Known Knowns);
• Decisions that you know will need to be made but don’t have the resources to resolve right now (Known Unknowns);
• And leaving space for the possibility that there will be decisions about the app that will need to be made that you aren’t aware of or can’t plan for (Unknown Unknowns).

As an example, it is common for mobile developers to get a feature request as part of a designer’s vision for a user interface. UI designs can be misleading – they can hide what should be happening underneath. However, customers often treat them this way, and you often have to help customers understand that they are best used as tools to better understand user requirements.

Asking the right questions helps clarify and resolve what the feature needs while leaving room for issues with the feature that will only become apparent later.

You could go about this by asking questions looking for the boundaries of the user needs: what would cause the feature to fall outside of the designer’s or customer’s vision and fail to meet the user’s needs?

Additionally, you could focus on how unexpected errors are handled. This might include questions like:

• What happens if the feature simply stops working for no reason?
• How will the backend handle that error and let the user know?
• If the error is recoverable, how do you tell the user how to fix it?
• And what happens if a partial error occurs, where only most of a feature works correctly?

How to get started with Mobile System Design

Below are some tips and tools you can use to integrate mobile system design more fully into your projects. This list is not exhaustive but includes some of the most valuable ideas you can read about in Tjeerd’s book when it comes out.

Diagrams

Tjeerd says diagrams are best for helping everyone know what people are working on, especially if you’re part of a team of more than half a dozen mobile developers. They can be a powerful tool for building alignment within a team and between the team and the customer, even if they are not a good way of capturing the details of the work.

Like UI designs, diagrams can be misleading. They are an abstraction or simplification of the ‘truth’ of how your app will work and look. As with UI designs, it is best to make it clear to the customer that using them is a tool to find out what they want.

Keep Your Backend Synced With Mobile

An effective strategy for ensuring the mobile version of your app keeps pace with overall product development is to focus on integration as early as possible in the development process.

This means focusing development early on making API calls from mobile to the backend, rather than the common tendency in mobile development to focus on integrating with a completed UI design. API calls are one element of app development that can be built in many different ways; by focusing on this element early, it’s easier to make changes and zoom in on making those small, critical decisions about how the app will work.

Not only is making an API call an effective way of sorting what is needed to meet user requirements, but the backend itself also doesn’t have to be fully developed to execute this strategy.

The goal is to fix any problems between the backend and mobile as early as possible, even while later developing a UI design. This avoids the classic scenario in mobile development where you start making calls late in development, only to realize something isn’t working, then need additional weeks of development to get it mobile-ready.

For example, if you have a screen that needs several types of data. Is it best to be able to retrieve all as one API call? And if you can retrieve all this data in a single format, as you might expect if you’re using a REST API, what does that mean for the scope and complexity of work for the backend development team?

Demos

Regular weekly demos can be helpful for sharing what different teams are working on – especially if they’re working on the same feature in parallel – and having constructive discussions about the overall system design of the app. They also can be an effective way of sharing ideas.

Demos are also a great tool for distributed teams. It’s easy enough to create a short video – even if it’s simply a screen recording with the developer talking their way through what’s happening – that makes it accessible for everyone and means you catch watch it later for team members in distant time zones.

For example, during a demo, the team responsible for Android development shows how a specific feature works for their version of the app. This is interesting to the iOS team because it was a way of delivering the feature that they hadn’t thought of. Meanwhile, the backend development team doesn’t like what the Android team has done because delivering it that way makes the API call taxing on the servers.

This has an advantage over traditional meetings or standups in multi-team environments, where it can be hard to understand what’s going on. It's difficult to envision how everyone’s work meshes together. Demos, on the other hand, make discussions more concrete and centered around what team members can easily see and understand.

Get updated on Tjeerd’s upcoming book

Thank you again to Tjeerd in 't Veen for sharing his ideas and for the privilege of seeing the draft of his book. Tjeerd is still finishing his book at the time of writing, but you can sign up here to receive updates when preorders become available. If you found this topic interesting, I recommend reading the book when it comes out.

Also, if you enjoyed this article and want to keep reading more about interesting ideas in Swift and iOS development, you can check out the latest content on our blog. You can also sign up for our newsletter, where, about once a month, I’ll send you updates on the latest news, tips, and tricks about all things Apple and Swift.

Streamlining your day-to-day workflow with automation can reduce friction within and between development teams. It also removes the most tedious and repetitive parts of app development.

But it can also be one of the most difficult things to do as an iOS developer.

We've chatted before on the importance of Continuous Integration but in this article we will explore this fun, sometimes complicated, but overall stress-reducing aspect of making iOS and Swift apps with a list of automation tools we’ve enjoyed using in the last year or that we’ve seen work well for others.

5 Automation Tools You Could Start Using Right Now

Sourcery

Sourcery is a tool for generating code using templates. Because coding can get tedious when you need to reuse the same code over and over, some developers have taken it upon themselves to create tools that effectively generate generic Swift code blocks for you. This is really useful when creating mocks or writing tests

Sourcery is also useful because it helps you eliminate repetitive code, improves your app’s overall architecture, and generally helps you be a much more efficient developer.

A paid app, Sourcery Pro, is also available, extending Xcode and giving the ability to create your own templates that can ‘understand’ your own code.

XcodeGen

XcodeGen is a Swift-based command line tool that creates your Xcode projects using file structures and project specs in YAML. These specs contain all the information in the project: targets, settings, dependencies… everything.

It’s probably one of the best automation tools you could be using.

It minimizes or outright eliminates the possibility of merge conflicts. This can be an enormous source of pain relief, as .xcodeproj files aren’t much to work with, as they are not in any way designed to be human-readable.

It not only saves time from not having to manually set up your own projects, it gives you a lot of flexibility in how you create the project while being easier to find things because you have control over the entire file structure rather than having to work within the structure that Xcode uses by default.

If XcodeGen is too simple for your team there’s always…

Tuist

Similar to XcodeGen, Tuist is also a Swift-based command line tool for creating and maintaining Xcode projects. Tuist is a little more complex than XcodeGen, for when you’re dealing with larger apps or you need more fine control over your project.

Where XcodeGen uses YAML, Tuist writes your configuration files in Swift. Tuist also comes with a range of caching features that XcodeGen lacks, including the ability to remotely cache using a cloud service Tuist offers. This means that with Tuist, you might expect to find shortened build times. If you want to learn more about automating Xcode project generation, check out this Runway article from former guest Jared Sorge.

Fastlane

Fastlane is a well-established platform for automating your iOS app’s deployments and releases. The platform's tools handle signing, certificate management, screenshot creation and help save you loads of time when releasing your app.

Fastlane is also designed to support CI practices, integrating with other CI systems (including Gitlab CI and Github Actions), and is easy to customize and extend for what you need.

Xcode Cloud

Xcode Cloud is Apple’s own (paid) service. As we’ve come to expect from Apple, the service brings together a range of different tools iOS developers were already using or familiar with so that you can do more without having to rely on anything third party or even without leaving Xcode.

This includes tools for running tests, reviewing user feedback, as well as deploying your latest builds directly from desktop. It is also fully encrypted, making it a secure place to create and store source code.

Can You Have Too Much of a Good Thing?

As much as we like automating away the boring, tedious and painful aspects of our work, it’s easy to fall into the trap of over-automating things. It could wind you up where you spend hours automating things that honestly would have been faster or more cost-effective if you’d done it manually.

As a guard against this, always try to answer the question, “Should I really be trying to automate this?” Does it make sense in terms of time and the amount of tedium avoided? But most importantly, does it make good financial sense? Automation can become very expensive if you’re not vigilant about what is needed to support it, or how it might complicate an otherwise efficient tech stack.

Additionally, overreliance on automation can make your code very brittle, causing things to fail when it comes time to upgrade or there’s a need to deal with something unusual that wasn’t previously identified as an edge case.

What are your favorite automation tools and platforms?

If you enjoyed this article, and especially if you found a tool you didn’t know about before, we’d love to hear from you – what are your favorite automation tools? Do you have any automation best practices that you think need to become more popular? Email us, or tag us on Twitter!

SDUI isn't a new idea, but it is uncommon. And some apps definitely benefit from this technique more than others.

We'll be covering: what Server-Driven UI is its advantages when it comes to multiple platforms when it's not a good choice critical pieces of advice to remember if you implement it

What is Server-Driven UI?

The current popular interest in SDUI seems driven mainly by several so-called "disruptor" apps. Airbnb, Lyft, Spotify, and DoorDash, to name some of the largest - all use SDUI techniques to varying degrees.

All these apps placed a high priority on consistent user experience across all platforms – if you use Airbnb, you can reasonably expect that it looks and works the same way whether you're on iOS, Android, or the web.

Server-Driven UI is the software architecture pattern of integrating the UI components with the data sent to your users' devices.

This is in contrast to the conventional way of building apps where only the data you want to display through the UI is sent by the API or server and design is setup only in the app's codebase.

The central idea of SDUI is that your server manages not only your app's data but also all the components, views and layouts you want to display.

When is Server-Driven UI a good choice?

Server-Driven UI has a few advantages over more conventional ways of making apps:

It makes the app "platform agnostic."

Let's say you have an app that you need to work on iOS, Android and in a web browser, you have a problem where each platform has fundamentally different ways of changing and rendering data. As a result, the same UI will work differently across all devices. So you have to develop ways for your app to display data correctly on each platform.

Traditionally, you might solve this problem by developing separate versions of your app for each platform – a cumbersome and expensive route. Or you might choose to code your app using a cross-platform programming language, such as Flutter, Ruby, or React Native. This can work, but it can be extremely challenging to deliver a consistent user experience across platforms because each will need tweaks or exceptions to be usable by each app client.

With SDUI, you overcome this problem by having the server send the data as well as the information about how that needs to be displayed. The app client (iOS, Android or web) can use that in a way that's native to its platform.

You can deploy changes faster and without relying on the user.

Versioning slows you down. Whenever you want to add or change features to something you have in the App Store, you must go through the time-consuming process of submitting it for App Review and make updates to your product page before deploying.

After having gone through the gauntlet of Apple or Google's App Review, you are at the mercy of the user, whom you must wait for. They will need update your app before you receive any feedback or data. This limits the speed you can iterate, test, and experiment.

SDUI gets around this time-consuming process by keeping UI configuration data on the server (with limitations. We address this further down). You can make changes to the UI without waiting for a version release, and the user gets the update immediately.

This makes SDUI an excellent choice for apps with dynamic interfaces. If your interface needs to be updated quickly, just like Airbnb this becomes a necessity. It also makes a great choice if you want to do lots of A/B testing. All you need to do is change your UI view and URL, and all your apps get the new look and feel you want to test.

You can build your app almost any way you like

As we've covered previously, we almost always recommend developing your apps natively for the platform. Cross-platform development is often rife with compatibility issues, code smells that arise from trying to get features to work on platforms they weren't originally designed for, and significant limitations on what you can do while maintaining a consistent user experience across devices.

SDUI might be the one instance where it's possible to have honest cross-platform development. If done well, you should be able to update your apps at the same time without needing separate version deployments for iOS, Android, the web, etc.

Instead of being forced to code your app in React Native, Flutter, or another cross-platform friendly language, you can use any server platform you want. You can use Swift, Ruby on Rails, NodeJS or whatever suits your needs and knowledge base best.

When is Server-Driven UI not a good choice?

There are a few use cases where you'll probably find SDUI is not a good choice, is ineffective or at least unnecessary:

You're only releasing for a single platform.

If you're only releasing your app for iOS or just Apple platforms, then many of the advantages of SDUI aren't going to matter. While it might still prove helpful for rapid A/B testing of your UI, there are limits to this, and in the long run, it likely won't show an enormous benefit over simply deploying to the App Store.

Your development teams are significantly siloed

One of the most important things about using SDUI is that, to be effective, you need to have all of your development teams working very closely together, as changes to the app UI will affect all of them directly at the same time. It takes time to build the initial framework and sometimes it can get quite complicated.

If your already spending the extra time with your server team setting up the SDUI and they have been operating completely apart from teams for iOS, Android, and web development teams, implementing will require all of them to have team meetings together. They will all need to create and agree on one shared template that the server will be returning. And generally, coming up with a generic page template appropriate for cross-platform development takes a lot of time and effort.

You've already set expectations from your user base about how your app updates

This is more of a warning for established apps about moving to SDUI - before you make such a big change, be sure to listen carefully to your user base.

SDUI does have its advantages, but abusing it with frequent changes could just as easily aggravate your users. How many times have you logged onto a web platform you use often (think Google apps or social media platforms) only to find the UI has unexpectedly changed, and now you have to spend time looking for that button or tool you need? While SDUI is great for making rapid changes, there comes a point where it might begin to negatively impact your users if they were already happy with how things were.

Important tips when using Server-Driven UI

To round things out, if you decide that using SDUI might be a good choice for your app, there are a few useful things to consider, especially if you're deploying to iOS:

There are different levels of SDUI

Not everything about your app's UI needs to be server-driven. Some apps are good to be 100%, but you may find your app only needs specific components to be server-driven. The rest can be integrated into the current app version.

All your UI components need to already be in the binary

For iOS and Android, any component or widget you want to render from the server must already be in the binary files of the app. This is the limitation we mentioned before on how much and how quickly you can make changes to your app's UI.

For example, if you have an iOS app view in which you want to do A/B testing between displaying a drop-down menu and a set of buttons, both the menu and buttons (whether SwiftUI or UIKit) need to already be in the binary currently deployed to the App Store. All you're doing is changing the order and appearance of components - all of which can be easily handled server-side.

This is where versioning is very important, as well as having your development teams decide how the app will handle anything from the server it doesn't recognize. For most development teams, logging the error and having the app ignore anything it doesn't recognize, but there should be a discussion and agreement around this issue.

Additionally, there also needs to be an agreement about what happens when a resource is unavailable – most frequently, when there's no Wi-Fi or network connection. You could use a local template that informs the user that a connection isn't possible but continues to support limited use of the app. But, because the kinds of apps that benefit from SDUI often use rapidly-changing information (think Airbnb or Lyft), you should have a strategy in place.

All teams need to use the same template language

Your API is mostly likely a JSON file that needs to be read by all clients – iOS, Android, web, or any other platform you're deploying to. Because of this, the template needs to be written in a language all your teams know and use. This ensures that all clients can parse the template and data correctly.

It doesn't have to be difficult to start using Server-Driven UI

The SDUI approach doesn't require you to go full ahead right out of the gate. You can start by thinking about what parts of your app's UI you want controlled server side. This can be small and simple, like widgets for displaying read-only data. By bringing it server-side, you can easily update and test the order, format, and appearance of your data.

It helps if you start with designing a very generic template – which might also be the most challenging part of the process, depending on how many development teams need to approve it. Once you're past that and are versioning your app correctly, it should be easy to start implementing SDUI into different parts of your app.

A Special Thanks to Mohammad Azam

We want to make a special thanks to Mohammad Azam, whose thoughts and ideas in our interview with him on the EmpowerApps podcast inspired this guide.

If you're really interested in learning how to get started with Server-Driven UI, we recommend you check out Mohammad's course on the subject over at Udemy.

If you ask developers about their recent experiences being hired and doing interviews, you’ll probably hear a lot of similar stories. And unfortunately, a lot of them are really negative. A lot of this negativity stems from the idea that when it comes to software development, companies should focus on hiring for only technical skills and expertise.

This is an outdated mindset, and it’s become extremely costly for companies who choose to sustain it.

In most cases, but especially for startups and growing companies, they need a mindset that prioritizes two things when hiring:

• Team players with good communication skills,
• And professionals who are agile at learning new things

In this article we’re going to cover:

• The practices you should stop doing in interviews
• What leaders and hiring managers need to focus on if they want to grow strong, inclusive development teams and what they can do right now to improve the hiring process
• Tips specific to the hiring of iOS and Swift developers

Current hiring practices are hurting everyone

It’s fairly well-established that the tech and software industry really struggles with hiring and retaining people. According to LinkedIn, the tech and software industry continues to suffer one of the highest turnover rates in the world: 12.9%. This is higher even than industries notorious for their high turnover, like hospitality and retail.

It’s also really expensive. Data shows it costs organizations anywhere from $43,000 to $50,000 to hire a new software engineer, and will spend upwards of six weeks’ productive time to do it.

However, as we noted before, many interviewing practices and tools, including popular ones that are sold as reliable ways of assessing candidates, essentially set your hiring process up to fail.

If you’re spending a lot of time on either side of the interview table, you already know how stressful and awkward it can be – you have the difficult task of divining whether you or your organization can have a successful long-term relationship with the other with no foolproof way of knowing they are the right choice for you. That said, stressing people out during interviews, including yourself, is always going to be counterproductive.

What You Need To Stop Doing When You’re Hiring

Arbitrary code tests

Have you ever made a candidate stand up and work out an algorithm on a whiteboard during an interview? These are invariably high-stress situations, which means you’re never going to see what their good quality work looks like with them. You may have even seen many people completely freeze up when put in this situation.

While there might be many developers who can complete them, code tests are a very poor way of understanding what a candidate’s abilities are. Many tests also rely on areas of computer science that are rarely used in day-to-day work.

Grilling candidates to see if they know everything

In modern software development, there is a high need to be agile and flexible in the way you work. Things change very quickly, and a good developer needs to be constantly learning new things in order to stay ahead in this field. Making sure that a candidate has at least a baseline of knowledge in the area of expertise you need them for is best evaluated as one of several indicators of their ability to learn.

What is important to avoid doing long rounds of interviews focusing on technical knowledge – more often than not, it puts both the hiring manager and your company culture in a negative light. It also has a tendency of making prospective hires feel unwelcome in your organization, and you lose out on recruiting the best people. It’s also time wasteful, as you end up needing 6+ rounds of interviews to explore someone’s knowledge of even small areas of software development.

Not giving any guidance or sharing expectations

A classic example of this happening is when the interviewer sits silently while putting the interviewee on the spot with the two above practices. Not only does this make things more awkward, but it creates a hiring process that selects for candidates who are arrogant - not surprising if the interviewer is unhelpful and hostile to having a conversation.

A key part of software development is communication – almost nobody hiring builds apps all on their own. And if you’re hiring for a team of any size, communication is going to be a major factor in the success of that team.

How to find the right candidate for the job

What follows is by no means exhaustive, but are just some of the things you could do that we know are good ways to learn about a candidate’s ability to learn, as well as their communication skills.

Code pairing

Code pairing is not only an easy, low-pressure way to check a candidate’s technical skills, it gives you a chance to see how a candidate tries to learn on the job and a glimpse into what they’re like to work with.

In a Swift development space, this could, for example, involve setting up a really basic app for iOS. You allow the candidate to use whatever tools they normally would to build an app and work through the steps to set it up.

But what you want to focus on as an interviewer is how they talk to you. Are they able to talk through code problems with you? Do they take suggestions or guidance well from you? How well do they iterate on their code in response to feedback? As a bonus, a challenge like this can be modified for a candidate’s experience level: you can set the bar for clearer communication, and cleaner code, for more senior developers.

Clean up your job descriptions

There often seems to be a disconnect between human resources, who write the job description, and the person who actually interviews developer candidates. This is most evident when you see job descriptions that ask for long lists of qualifications that are, at best, tangentially related to how apps and software are made.

Especially given the recent employment climate, all job descriptions like this do is scare away good candidates because they both make people feel unqualified, but also communicate that you don’t really know what you’re doing in hiring for the position.

Focus on communication skills

There are many problems that arise in software development when you don’t select hires for their communication ability. It can’t be understated how much successful development relies on professionals being good at talking to each other, with management and with product ownership. As a manager you probably experience this where members of your team can’t talk to each other effectively, saddling you with the task of mediating between them. That’s hard to work with, right?

So how can you figure that out during interviews? You can ask them questions that are relevant to the day-to-day life at your company: tell them what routine is like and see how they react. If the team is expected to have lots of meetings, you might as well be clear about that, instead of hiring someone who can’t stand meetings.

This also relates to making your hiring process diverse and inclusive: if you can’t be honest and transparent with candidates about how work happens and how the company is managed, you may have a problem. If you can’t do this without feeling the compulsion to make excuses or downplay things, especially in front of candidates who are underrepresented in the organization, it may be time to take a hard look in the mirror and make changes before you even start hiring.

This also goes the other way as well: be wary of any prospective candidate, or even a recent hire, that struggles or avoids talking to others that are different from them: be that a coworker in a different technical discipline, someone in a higher or lower position of authority than them, or a team member of a different gender, ethnicity or cultural background.

An easy, low-stress tactic for ensuring someone can talk with everyone in your organization is to invite them for lunch. Observe them having casual conversations with the people they could be working with. At the same time, let the team know you want them to feel comfortable, and avoid having it feel like an awkward attempt at networking.

On hiring iOS and Swift developers

While the above can be applied to hiring for almost any software development team (and even teams that have nothing to do with software), there are a few things to note specifically when hiring in the iOS, Swift, and Apple space generally. The state of the Apple ecosystem is currently changing very rapidly: in the last few years, we’ve seen a lot of big changes in the frameworks we use and even the way we think about how we code. This really underlines the need to hire people who are good at learning new stuff really quickly.

There are rapidly growing market segments with peripheral devices. The Apple Watch is already coming into its own Meanwhile, there are lots of brand-new features released each year on the established platforms of iOS, macOS, and iPad. And very little of this development can be planned for – we usually only get a few months to find out what Apple is putting into its latest release.

At the same time, it’s important to recognize that no one can know everything, especially in Swift development. It should not be a failure or weakness if a developer needs to Google or use Stack Overflow to figure things how. In fact, you will probably be hard-pressed to find a good developer that doesn’t do this – they are often where coding professionals come to share their ideas, learn from others, and contribute to their professional community. Along with forums, social media, and Github, online spaces like these are a cornerstone of professional development, especially for newer programmers and developers.

If you choose to do code pairing with an iOS developer candidate, it is perfectly acceptable to tell them what to expect at the start of the interview: walk them through everything that will happen during the interview, including when and how the code pairing will take place. By doing this, you not only reduce the stress of everyone involved, but you give the candidate an opportunity to mentally prepare, which means better quality work, and potentially a shorter interview, reducing your time cost.

• Do you need a cloud service?
• Should you run your own server?
• Should you use CloudKit, Firebase, or another option?

We are going to dig into these questions and more to help you choose the best backend and cloud services for your iOS app.

Is the Best Backend Actually No Backend At All?

First, it's important to know that cloud services aren't needed in every case when it comes to an iOS app. What can you do without them - A lot, actually.

A thing to know about iOS apps is, that in a lot of cases, people don’t need the cloud to store their data. It can just be stored on their phone.

When you're building an app, you should consider whether you really need something stored in the cloud. In the end, you could save a lot of time and money, if everything can be saved as a file, keep the data on the phone, and maybe only back that data up into cloud storage.

In cases where you are dealing with private or sensitive data, it's a good idea to stick with keeping it on the phone. This is especially true when dealing with third-party apps like Twitter, YouTube or another API where you're not really storing data but storing it in the third party's structure. You can use that API as your database.

As an example, in an app we built, all the data was essentially stored using Core Data. The data was all local because their time and budget didn't allow for anything else. There was a manual backup process put in place that would run and create a zip file of the data that they could store on the cloud. If they needed to restore it, it was easy to retrieve it and restore the data to their phones.

Choosing Cloud Services for Your Best Backend

Using cloud services for your iOS app backend can be helpful if you're storing data or syncing across multiple devices. For example, note-taking apps that are available on all Apple devices can use a combination of iCloud and CloudKit to store information on the backend. When a user opens their notes on their Mac or their iPhone, they are always available and accessible because they are stored in the cloud.

If you've decided that you do need backend storage, there are a few things you should consider before making that choice.

The Purpose of Your App: MVP Vs. Enterprise

The first thing to consider is your timeline, budget and being clear about the purpose of your app : Is it a simple Minimum Viable Product (MVP) or an Enterprise app you mean to support over the long-term, meaning it needs to be well designed from the start?

An MVP is a simple app for proving it's something your customers will actually want. It's something you need to get out quickly and is most likely a bare-bones version of the features you think your customers will want.

On the other end of the spectrum, there are enterprise apps that need to be well-architected right from the beginning. If you're going this route, you're going to want something that is more robust and customizable than the MVP. Whereas with an MVP, the best backend is something that's simple, easy, cheap, and will get the job done quickly.

When you are writing your Swift app, you'll want to make sure you have some healthy abstraction with your backend communication. That way, you will be able to pivot easily if you decide to use a different service at a later date and your users won't see anything different on the front end.

What devices will your app support?

There's a variety of devices you may need to support:

• Are you only supporting Apple devices?
• Or are you going cross-platform and supporting Android?
• Will you have a desktop, and will it be browser-based or an application?
• And if you’re doing a desktop application, will it support Windows and/or Linux?
• Does your app need to support connectivity with the Internet of Things?

These are all questions to consider when deciding what backend services to use.

If you're only supporting Apple devices, you may want to consider CloudKit. If you're supporting Windows or Android, Firebase might be a better option. In either case if you have the expertise, budget and time, running your own server in the cloud might be an option too. We'll discuss these options in detail later in the article.

Complex Vs. Simple Queries

Many tasks use relational data, which are best performed using some sort of SQL database. Unfortunately these can be pricey. Conversely, many simple document-based cloud storage options are cheaper. The drawback with these services is that relational data becomes complex to query.

Therefore, if you're willing to offload a lot of the complexity of a good query over to the device and want to save some money document-based services such as Firebase might be a good option. In these cases, you could consider caching your complex data for later rather than querying the data each time. Remember, a simple query would need to lookup data with a particular ID only.

You need to ask yourself if you're willing to offload a lot of the complexity of a good query over to the device, or if it is more important to have that information on the server. The best backend for your iOS app might not be the easiest to query but the cheapest and easiest to maintain, depending on your priorities in this regard.

The Expertise of Your Team

This is a big factor because if their expertise is .NET, you're probably better off using a Microsoft backend with an SQL Server and C#. If you're already getting a decent price on Microsoft Azure, for instance, use it because that's what your team has expertise using.

If your team is well versed in Swift, you may want to consider Vapor for your backend. You can check out our review of Vapor, but you should know that since we wrote that review, Vapor has improved significantly as a framework since its Version 4 release.

User Interface (UI)

We also recommend doing some user-focused design to come up with the kind of data that your users will need. Afterward, work your way back towards how you would need to store that. For instance, you can start by building out the UI of the app and essentially fake the data to make sure that data is what the customers want and then go back from there. Get your UI taken care of because that's the thing the users are going to see.

SwiftUI has now become the first tool you should be looking at if you’re building an app natively to iOS (or any other Apple device). While you’re likely already familiar with it, in case you’re learning this for the first time, do check out Apple’s introduction to SwiftUI. As well, we have a short article that goes through how SwiftUI changed UI creation from what we had before.

SwiftUI uses a declarative way along with observing changes to data similar to HTML and many Web frameworks. As opposed to UIKit which was based on an imperative method (i.e. using commands) and a delegation pattern.

These factors, plus the budget you're working with and the time you have to spend are all factors to consider when thinking about back-end storage.

So, what are your options?

Once you've asked yourself all these necessary questions, you'll want to start looking at the options that fit your needs and budget. If you feel you need backend support, you'll need to decide the best option for your app and your user. Here are some options to consider.

The advantages of hosting your own is the fact that you can customize everything down to the minutiae, but the burden is on you to make sure everything is set up correctly. Along with cost and maintenance, services such as CloudKit or Firebase pretty much can take care of everything are much cheaper. All you need to do is write your app code and get your database set up.

Hosting a Server For Your Backend

The most customizable and robust option is just to host your own server. You can buy your own server and host it at a site with a virtual machine like Amazon Elastic Compute Cloud(EC2), Linode or DigitalOcean. However, you may not want a complete server both due to the cost but also the need for maintenance.

If you want some of the control of setting up your own server with minimal cost and maintenance of it, Heroku is a great option. If you're starting from scratch and want something to play with, their free tier is pretty decent and includes a PostgreSQL database.

Speaking of PostgreSQL, you’ll need to set up your own database, as well as other server software. Here are some specific options to consider:

Databases

• PostgreSQL
• MySQL
• MariaDB
• MongoDB
• SQL Server

You’ll also need something to serve content whether it’s images, JSON, or HTML:

Server Software

• IIS
• Nginx
• Apache

Also, consider some other services such as:

• Cloudflare – for monitoring, caching and serving as your content delivery network
• New Relic – for monitoring and security
• Supervisor – for services
• GraphQL – a powerful open-source query language you can use with multiple architectures and API configurations

If you're working with a simple MVP or releasing only for Apple, I would not recommend hosting your own. If you have simple needs, go with the simplest solution and then plan on scaling out from there according to the growth of your own needs.

CloudKit as Your Backend

One really affordable option worth exploring in more detail is Apple's back-end storage system, CloudKit. CloudKit is fairly simple to use if you're sticking with iOS. It comes with push notifications and is completely native to Apple. It also enables you to transfer ownership of your apps, which is a big help if you are building apps for clients.

If you're running a Mac app or an iPad app or using an Apple Watch or Apple TV, CloudKit really easy to use. It also includes a JavaScript component for the web. When using CloudKit, you would be fine offloading some stuff onto the iPhone itself if the data isn't too complex.

Firebase as Your Backend

Firebase is the most popular mobile backend as a service not only because of its price but also because it's available on a plethora of devices. Specifically, its Cloud Firestore is a NoSQL cloud database for both client and server-side development. Firebase incorporates features from both Firestore and Google Cloud (GCP) On the surface, it seems really appealing but you should think carefully before using it for certain projects. If you want to learn how to do real-time database integration in a web browser and you don't want to introduce apps where you have to create a lot of extra code in order to access data, Firebase is a great way to go about it.

We recommend using Firebase and specifically Firestore for when you don't need to do lots of complex queries; this depends of course on how your app’s data is organized. It’s worth noting that while Firestore, and Firebase products generally, are popularly believed to only be best for developing really basic app products, this isn’t really true. using Firestore as a backend also comes with live support for critical components like app security and authentication. All this to say, it’s important to study it before you jump in to make sure it’s a good fit for your needs.

If you want to learn more about Firebase and Google Cloud Platform, I highly recommend checking out this video from their team. or our episode we did with Peter Friese, who's Developer Advocate at Google on Firebase:

Final Tips

We know we're leaving you with a lot of information, luckily we've created a cheat sheet based on this article to help you get a summary. As a final tip: When considering any solution, check to see if there are any big companies using them. The best backend for your iOS app needs to be something that's rock-solid and stable and gets a lot of support, so it’s worth checking out what the big players are doing. You can be sure companies with a lot of money to spend will have taken the time to research and vet these solutions, so as a general rule their choices will be a little bit safer than an under-researched option.

Typically, large companies will go with one of the big cloud service providers: AWS or Microsoft Azure; Smaller companies will go with Firebase, CloudKit or host on Linode or DigitalOcean.

Whatever you choose, remember, if you need to pivot, do it early. Don't do it when it's too late. If you feel like your data isn't a good fit for what you’re using, make the change as quickly as you can to avoid burning out constantly trying to get your data to fit.

It's already very challenging to stay ahead of the latest developments in Swift when major releases come around. However, if you want to take full advantage of transitions in the Apple ecosystem, you must have three things:

• Good habits and learning practices
• Time to experiment and explore new developments
• Helpful mentors

How can you do this in a way that is both effective and best drives your business goals?

I will share an overview of how to do this in the context of learning one of the more critical features of Swift software development: Application Programming Interfaces or APIs.

Swift Development Changes Swiftly

Things have been changing very quickly in Swift development – Apple has clearly taken the direction of trying, as much as possible, to enable its developer community to create apps with their own tools and services.

Chief among these developments has been the introduction and growth of SwiftUI, which is set to replace a myriad of tools and libraries we've relied on to develop interfaces for our apps. However, it's been a difficult transition for anyone who was heavily invested in the old ways of doing things, such as Objective-C or UIKit.

These changes demand that we rethink how we code.

The problem is that it's easy to get into the habit of coding things a certain way. It's efficient, easy, and gives consistent results. But, it tends to create a barrier to learning other methodoligies; there's always another method to build.

In the end, old habits are difficult to break.

Slow Down!

There are few things worse than developing something using an API, only to discover that you can do more or you're doing it wrong. Additionally challenging if your software architecture can't support the additional features. You're then stuck with the pain of having to reconfigure everything.

The best way to avoid this is to get in the habit of taking things slowly. Instead, it pays to dig into a new API, especially if it's large and serves a critical function within your app.

Learning an API this way ensures you avoid scenarios where development has progressed significantly, only to discover there was something you needed to do right at the beginning. You want to avoid having to go back and fix things as much as possible, as it's always more costly than spending extra time mastering the capabilities of the API.

It's a reality of software development that new things always take more time to learn than you think they will, especially if you explore how different developers accomplish similar things. Even if it's an area of development you're well-versed in, seeing how others do things can give you new ideas or even whole new ways of thinking about something you already know.

Another problem with developing software quickly is that the results will often only work in a tight range of use cases. Software is supposed to be… soft. We're supposed to be able to change things easily, and managers and clients often expect us to do so quickly.

The scenario we want to avoid, as developers, is where you're copying and pasting things from Stack Overflow to get things moving. We've all done it, but it is dangerous for our apps' viability and our sanity. Because if anything changes – frameworks, APIs, project requirements – you risk having to start over.

Understand How You Learn Best

It is rewarding to figure out how you best learn new things. For example, you might want to spend your time on YouTube, watching other developers walk you through the various things a specific API can do. This is especially helpful if the API documentation isn't well-written. It's also a great way to learn how to use an API with different architectures.

On the other hand, you might find it easier to absorb information when it's written down and prefer blogs exploring API use cases. Or you might like to learn through listening, following a podcast where developers discuss similar challenges to what you're working on. All of these options are valid and give the Apple development community lots of options that fit different preferences and contexts.

And it's normal to find that you'll click with specific content creators, where others might go over your head. For example, you could take an online course on how to use SwiftUI and struggle to understand anything, while another course covering the exact same material might make perfect sense to you. Our podcasts page has a great selection of guests who are content creators so that can be a good starting point.

Finding the right content creator

The great thing about the Apple development community is that there is no shortage of different creators covering all aspects of app creation. For example, here at BrightDigit, we have a collection of tutorials covering various aspects of app development. Another example is Stewart Lynch. He has a YouTube channel with videos that walk you through various iOS and other Apple development topics.

The most important part of learning when it comes to APIs is to experiment. Discover all the things an API can do, including outside your own use case. It helps to start small and, where possible, modularize, so if it turns out that something you learned later becomes important, you can include it without refactoring or making a mess of your code.

Find a mentor

Finding a good mentor, or fostering mentorship within your team, is one of the best ways to support your professional development. Mentorship is not only an excellent system for learning; it can also be an effective employee retention tool for organizations.

There are just a few things to remember when looking for a mentor that always bears repeating. The first is, don't be afraid to ask. If you're new to the field or new to a company, you need to ask questions if you're going to get ahead. Mentorship often shows us what we don't know that we don't know.

The second is that, much like content creators in the Apple development community, there are some fantastic people out here who are more than happy, if they have the time, to help you get where you want to go.

The third thing, sadly something that gets missed more often than it should, is showing gratitude. People often want to know if what they told worked, and if it didn't, why not?

Learning new things is hard, but you can make it easier

A special thanks to Stewart Lynch, for the ideas he shared on the EmpowerApps podcast with us that inspired this article.

If you found this helpful, or if this leaves you with more questions than answered, we would love to hear from you! You can reach out to Leo on Twitter at @leogdion. You reach out to us directly here.

Localization is one of those things that needs to be done well, the first time. It is extremely expensive to fix poor localization, often winding up as a giant bug made up of lots and lots of small bugs, proportional to the number of localized strings you have for your app.

This article is for any developer or business that requires localization as part of breaking their iOS app out of a single market.

Below, we’re going to cover:

• How to get started with localizing an iOS app
• Apple’s localization features and API that can help streamline localizing
• What you need to do when it comes to testing

What is Localization, and Why Does it Matter?

Localization is adapting software to be usable and relatable for other languages, countries, and regions. Not to be confused with translation, which only covers the conversion from one language to another, localization seeks to make everything about an app contextually appropriate.

This may include:

• Altering of images and icons
• Creating documentation
• Creating new audio
• Altering or removing part of the app in response to cultural preferences or legal requirements
• Redesigning user interfaces so that things like space between objects, navigation
• Rebuilding parts of the app if there are different technical requirements in the target locale

There are two related terms you should know:

Internationalization is the preparation of something for localization.

In this context, it generally refers to the strategy and design of an app so that localization work is possible and relatively easy. The other is:

Culturalization, which can be considered to be a step beyond localization – not just making something contextually appropriate, but culturally meaningful to users in your target market

Finally, all of this should be seen as a similar mindset to that of accessibility. You ideally want your app to be accessible by people everywhere, or at least, all people likely to use your app in your given market.

Only 17% of the world’s people speak English, and a little more than 4% of the world could say to be part of the United States' cultural context. Therefore, most of the world’s market opportunities become available for a U.S.-made app that can be localized.

How to get started localizing your app

Getting started localizing an iOS app is really simple – all you really need to do is to create a new Xcode project and add a localizable.strings file. What you need to make sure here is that this is separate from your executable code. This way each localized version of your app’s content and assets can be developed independently from the work of developing the app’s codebase.

Having all of your strings stored in one place apart from the rest of your code should be seen as best practice. It also makes it easy for non-technical professionals and technical writers to easily find what’s in the app and review the content without having to search everywhere for a specific string.

Apple’s Localization Features

In general, it’s a good idea to let Apple’s own systems do as much of the heavy lifting as possible. Apple has gone to fairly significant lengths to make its products usable in every significant global market. For instance, Foundation APIs allow you to express dynamically-generated values across locales – things like dates, weights, measures, and currencies.

As an example, a new Formatter API has been introduced with iOS 15. Unlike previous APIs, you don’t have actually have to create new formatters and can convert data directly to a localized string. This makes the new API substantially easier to use than its predecessors.

You don’t have to initialize the formatter either. You simply code in .formatted() and then specify the format you need for your output. This is particularly useful for locales that don’t have universal measurement styles, for example, Canada, which uses a mix of metric and imperial measures. Apple’s formatter has already accounted for this, and will correctly output the right measurement for that locale without you having to calculate it yourself.

A new feature that can be particularly helpful is the AttributedStrings structure. It allows for easy localized attributed strings using Markdown (previously you could only do this using complex HTML). This way, there isn’t any HTML in your .stringsdict file that a translator or marketer won’t be able to read. One particularly cool feature is that this structure can read inflection marks, especially useful for doing language localization, especially for languages that use gendered words, like French and Spanish.

As always, remember to test

Like all things related to accessibility, localization should always be seen as an ongoing process, not a one-and-done. You will make mistakes – if you’re fortunate, you might even have your users constructively tell you if something is not correct or appropriate for them.

Build a good relationship with your translators and transcreation writers:

You don’t just send your assets off to them, get them back and just submit them to the app store. A good process might first include integrating them with the app, then sending revisions back for anything that doesn’t work, and do a limited beta test in a target language.

Always try to get a second opinion: mistakes might only be grammar or syntax errors, or they could also be something that’s culturally or contextually problematic. In either case, there’s always the chance that something is missed because one translator or writer doesn’t know a specific cultural reference, or they’ve worked for long on a piece of text they can’t see simple errors.

Zach Brass - Localization for Beginnermediates from 360|Conferences on Vimeo.

You're now turning to ways to monetize and decide to use in-app purchases. And you didn’t realize how many decisions you would need to make around this small but often overlooked part of app development.

You need to be careful when working with in-app purchases. They can be incredibly effective, but they will hobble your user experience if poorly executed.

Like many things in development, they might seem simple but will create headaches for both your developers and your business if they're not well-aligned.

This article covers three main areas of in-app purchases:

• Purchase types
• Marketing and copywriting
• Purchase testing

The goal is to show you how to avoid these pitfalls and point you toward success.

Which Purchases Type Is Best For You

In almost all instances, adding in-app purchases to a Swift app will involve using the StoreKit API.

Apple has good documentation explaining the different types of in-app purchases available on their platforms – the following is meant as a simple summary to help you consider which type of in-app purchase may be best for your app.

Consumable

This is the go-to purchase type for games or apps which use any credit-based system. First, you sell a consumable to the user. Then, the user spends the consumable to get a bonus, boost, credit, content or digital good. Once they've depleted your consumables, repeat.

Examples of apps that might use this purchase type:

• Games
• Dating apps (that temporarily boost your visibility on the platform)
• Social media apps
• Content library apps (where individual pieces of content are sold as consumables)

Non-consumable

These purchases permanently unlock premium features in your app. We recommend this if you have an app that is free to use but offers "pro" functionality or additional bonus content. This is also the recommended purchase type if you're offering a product or tool that you don't plan to further develop once released.

You might also use this if you're offering a so-called "paymium" app: The app costs something upfront to download and use, who then can pay a little more to get additional features or content.

This can be an excellent strategy to keep the initial download price of your app low and the buyer friction this creates while still being able to monetize the full range of your app's capabilities.

Examples of apps that might use this purchase type:

• Photo/Illustration apps (to unlock additional features or filters)
• Dating apps (that over an improved experience for a cost)
• Games (for permanently unlocking cosmetic items)
• Any apps that use ads to monetize but offer a paid version that removes ads

Auto-Renewing Subs

Apps using this in-app purchase provide ongoing access to content or features. Users are charged recurringly - commonly monthly - and must manually cancel their subscription if they wish to stop.

You'll most likely want to consider this if you're app offers a lot of multimedia or provides ongoing services to your user, commonly Software-As-A-Service (SaaS). This method fits well with a remarkably high number of apps on the market and gives your business the stability of recurring revenue.

The main pitfall you want to keep in mind is that by going down this path, you set user expectations and behold yourself to Apple's own requirements to add to and increase the value of your app continually.

Examples of apps that might use this purchase type:

• Streaming services
• SaaS platforms
• Learning/Educational Apps
• Finance apps
• Fitness/Meditation Apps

Non-Renewing Subs

As the name implies, this purchase type allows users to access features for a limited time, and users will need to buy new subscriptions each time to keep continued access.

These purchase types are also useful with apps that do limited sales or offerings, allowing your users to subscribe, but only when it is relevant.

Examples of apps that might use this purchase type:

• News apps
• Games (offering season passes)
• Seasonally-relevant apps, where you can reasonably expect users will only use it for part of the calendar year
• Patronage apps, where you can subscribe to support content creators (think Patreon or Twitch)

Marketing

When it comes to marketing a Swift app, it pays to spend lots of time understanding your users, maybe even before releasing your app. This might include:

Visiting forums

A good place to start is Apple's Support Community. You're looking for feedback from users of your app, but if your app serves a specific need, look for related questions that users are asking. If you're working in an established niche, look for users' queries and complaints about your competitors' apps. This is a simple, low-cost way of learning about your users, especially when you have user numbers in the thousands or less and analytics data will likely be less helpful.

Start a Mailing List

Before you have an app in the App Store, you can start a simple mailing list and build relationships with prospective users. You can also attach this to a waiting list for your unreleased app, making it helpful in gauging early interest in your offering.

Additionally, you can get early feedback by showing your list tastes of your app: what it does, what it might look like

Interview Your Users

Talk to your users through forums and mailing lists suggested above or directly if you have that kind of relationship with your user base. Ask them about their values and what features they like the most and least.

This is super important if you plan to put parts of your app behind a paywall. You will want to get a good balance of features that users get straight away and understand well enough to convey the value of paying to gain access to the rest of your app. Getting it wrong could make or break your app.

Apple's Internal Marketing Tools

Additionally, Apple provides several tools to assist in marketing your app. Apple's documentation is good, so we're linking them here.

• In-app events
• Family sharing
• Promoted in-app purchases
• Subscription offers
• Localized Pricing
• Bundling
• Promo Codes

Testing

One of the biggest challenges of monetizing an app is where you want to put up a paywall.

On one side, you might require the user to pay for the entire app upfront in the App Store, but potentially make it difficult for users to fully understand your app's value. On the other hand, you might choose to put only very specialist or niche functionality behind the paywall, which most users will never want.

While talking to your users can give you strong direction for where your users find value in your app, there is no substitute for good testing.

It's easy to into certain traps when testing different kinds of in-app purchases. One of the most common is relying too much on analytics and A/B testing during the early days. If your user base is small and you don't have a long history of established user behaviour, it's doubtful that your data will have statistical significance.

Avoiding too many platforms

Another common mistake is testing and deploying on too many platforms on release. This is particularly common with apps made to be cross-platform between iOS and Android. As I've written about before, this strategy often leads to a worse UX experience and more costly maintenance. Native app development generally will deliver a better experience and performance.

But this point can lead beyond that: for a Swift app, it could be better to focus on delivering a creative user experience on, say, iOS and watchOS, and only later, invest in deployment to macOS.

One tool for getting early feedback when useful user data isn't available is TestFlight. It allows you to experiment with in-app purchases and get all-important early insights shaping your messaging, design, and user experience.

In this way, you can see rapid results from testers when trying different purchase types. You can also test adjusting your paywall and get feedback on various marketing and sales messages, including localized messaging.

We hope this gives you a good starting point for discovering the optimal way to monetize your app and make the best use of in-app purchases with your Swift app.

If you'd like to learn more specifically about using in-app purchases, we also invite you to visit our friends at RevenueCat, whose advice helped us put together this article. RevenueCat are skilled professionals at growing app revenue for their customers and masters of getting the most of in-app purchases and subscriptions.

It's a balance between needing the app to remain fast while also adding new features that help meet business goals. It's even more challenging if you're trying to scale an older app with a lot of functionality, forcing you to disentangle legacy code.

This guide will help anyone looking to scale up their iOS app and what you can do to make the development process move quickly and smoothly.

Who is this for?

This is for organizations, especially their development managers, that are:

• Starting to upgrade an app running on an older codebase
• Managing many people working on the app over its lifecycle
• Maintaining an app where a significant amount of functionality has been added since initial development.

Design your app around your people

If you're trying to scale a large app, one of the most effective ways is to break up your codebase into small, manageable parts. The same principle also works when you have a large team doing the development work.

It’s a lot more manageable to organize the work of scaling an app with small teams. Each team should be interconnected and coordinated, but they should be able to do their work independently of each other.

There are a few reasons why this is ideal:

• It keeps code quality high by limiting the number of people who need to interact with any specific part of the codebase.
• It's faster and easier for your developers and engineers to organize their work when you only have to coordinate with three people instead of thirty.
• They can better adapt to change – a small team with a high understanding of their part of the codebase can adjust to the evolving requirements.

My advice is to put your teams before your app and redesign your app's architecture to support your team structure. This strategy helps avoid time-consuming merge conflicts.

As for team size, 3-4 people per team would be ideal but anything more will see a loss in agility and communication between team members.

How to do this when redesigning a Swift App

For the last few versions of iOS and with the widespread use of SwiftUI, it's become easy to structure your codebase into easily manageable components. This makes it easy for each team to develop a component as a framework or Swift package and then ship it with an app without waiting for another team.

Modularization, or a microapps architecture, is a good strategy for developing a complex app while keeping merge conflicts and build time low. Swift Package Manager and Xcode allow you to divide even the most minor component of your app into discrete modules, effectively making each an independent codebase.

Initially, this may be challenging, particularly if you have a lot of legacy code or poor documentation. But, the result is that each of your small teams can work on one module at a time and iterate quickly, as it's a tiny codebase that takes relatively little time to compile.

If done correctly, each team should work within the app architecture without running into issues because of another component.

Limit Your Tools

While modularization is very effective when working on large, complex apps, many things can still go wrong. To avoid this, you will want to make sure there is an agreement, across all your teams, on what tools and libraries they use when working on your app.

This is especially important if you need anything third-party, which cannot always be relied upon to be properly documented or updated as often as you’ll need. It can also devolve into development relying on specific people knowing what's going on – the very thing this strategy is supposed to help you escape from.

Additionally, if a specific tool or library is needed, allow for extra time to educate your teams on anything they're unfamiliar with. Yes, it will slow things down, but it will save you massive headaches later.

Security work is hard but worth it

On the subject of things that are difficult but worth it: data security on your app.

Apple has a range of tools to keep things secure. But, unless security is their dedicated specialty, it's reasonable to assume that many developers may not know about all the choices they have.

For example, you can store a lot of secure information on the iCloud Keychain. However, this is sometimes not done. A developer may not check the security of their network connection.

A sign that is happening is if you're using a lot of App Transport Security (ATS) exceptions in your Property List (PList) File. This may be a possible sign of something going wrong, such as:

• Data is stored in a non-secure format. Few things could be worse than having sensitive user data stolen from your app because you're storing it in the phone's documents folder instead of the keychain.
• You're using a third-party Software Development Kit (SDK) which is not up to date.
• You're allowing an older encryption format or protocol – using anything that's not current when it comes to security increases the risk of someone intercepting or changing data on your app.

Apple has a great piece of documentation that covers security on iOS. While it's mostly a general overview, it is an excellent starting point for any iOS developer or development manager who wants to know what security features and mechanisms are available for iOS.

Focus on good craftsmanship

If you're a manager of Swift developers and you've made it this far, it's probably quite obvious but worth making the point: you will want to do everything you can to help your devs focus on good craftsmanship. We talked about this in the article on What You Should Know About iOS Software Architecture

What does that mean? It means they have the knowledge and time available for thorough unit testing and running automated tests. It also means allowing your developers to do more exploratory work, both with the app and on their own projects, as an investment in their professional development.

Asking your teams for multiple ideas when dealing with big issues and giving them the time and resources to do so can pay huge dividends. Talk to them about why they may want to code things a certain way – it will make it a lot easier when they or you have to explain to management or the customer why things are a certain way and the value that brings.

The result should be better goal alignment within your organization and between the organization and the user.

It’s also common, in scenarios like this, to have designers not specifically familiar with iOS, creating UIs that look great on other platforms, but end up looking messy and buggy when ported to iOS. 

This is understandable. iOS UI design can be difficult. But, as understandable as it is, neglecting the app UI can sabotage even the best-built app if it means people experience friction using it.

How can you create a UI for your iOS app that delights your user without making it difficult to maintain? Like many things in software, a little bit of planning goes a long way in avoiding common mistakes. Here are four mistakes you see in iOS app UI design or when working with UI designers.

Mistake 1: Failing to Communicate

UI designers and app developers usually have very different skill sets and notice different things when looking at the same app. This distinction is often missed on a lot of projects.

On one hand, a designer may not understand all the code that has gone into the app. So, they won’t know what constraints they need to consider when designing the UI. On the other hand, a developer may not understand why a designer specified a particular layout.

The unfortunate reality is developers and designers can be confused by each other's work during a project. This means missed opportunities and deadlines, frustrated professionals, and time and cost overruns.

Avoiding this mistake is relatively simple: create time and space for both designer and developer to communicate directly in a way that works for them. It gives them room to develop a mutual understanding of both what the app can do and how that can be designed to create a great user experience.

Mistake 2: Not Respecting The Development Environment of iOS

One error people often make is not recognizing the specific constraints of building an app for iOS. Apple’s ecosystem is unique, requiring you to do things a certain way. There are limitations that are either different or don’t exist on other platforms. This affects everything – from button placement and usage, to what fonts you can use and in what sizes and weights.

This can be challenging if a designer isn’t specifically versed in iOS. There is an enormous appeal in having an app that you only have to build once and can be used everywhere. But it's difficult, and sometimes impossible, to take what you have on a website or Android app and make it look and work the same way in iOS.

Trying to shoehorn an Android UI design into iOS will often lead to shortcuts and hacks that work, but leaves you with an app that doesn’t look good and/or work reliably.

When it comes to both iOS development and design, if you don’t want headaches later on maintaining the app, you’re far better off building and designing your app natively. Apple also provides guidelines to their platforms to help guide both the design and development of the app. And with the widespread deployment of SwiftUI, Apple is encouraging us to make it easy for ourselves.

Mistake 3: Not Being Consistent With Design

Related to the above, an issue app designers run into is trying to design everything to be as customized as possible, but without consistency. Designing this way is nothing new. It’s very popular and successful in web design, with whole rafts of different pattern libraries and tools available.

But in iOS, this is more difficult to emulate, resulting in design elements that are a hassle to update. They might also be only possible with third-party plugins and libraries, creating a lot of dependencies for the app.

To avoid design inconsistency: having a single pattern library for an iOS project is a good idea, but only one. This means both elements aren’t going to have to be designed in every instance and ensures consistency in appearance throughout.

Hopefully, SwiftUI will likely make it easier to create pattern libraries, making this mistake easier to avoid as time goes on.

Mistake 4: Trying To Do Too Much With An App

The other mistake you often find with design inconsistency is an app’s design trying to do too much. Nowhere this is more evident than with widgets in iOS 14, where a designer has tried to cram as much as possible within it.

Widgets should be all about focusing on communicating a single idea, message, or bit of information to your user. Widgets, by design, need to be glanceable – they exist so people can get information quickly.

For example let's say you have a weather app. It can show the users lots of different details about the local weather. A good widget for an app like this should ideally focus on only delivering one detail at a time – such as the current temperature. However, users may also want to frequently know what the current forecast is as well.

The mistake happens if you design a widget fitting both temperature and forecast together at the expense of no longer being glanceable. Sure, you've maximized available space, but your users will no longer find it easy to look at quickly.

Additionally, you also have to consider the different sizes of iPhones. A widget that’s comfortable to look at on the 6.7” screen of an iPhone 12 Pro might be difficult to read on the 5.4” iPhone 12 Mini. And with the tendency for tech professionals to go in for the biggest and best available, this can be easily missed by both developers and designers before going live.

For apps like this, a good rule is to always give things more space on the screen than you think they need. If you need to put that information somewhere, you’re best off:

1. Offer the widget in larger sizes
2. Creating two different widgets for each piece of information; or
3. Have one widget, but make it easy for your user to change the information displayed.

Consider how much of that data is really necessary, and what your users ask for. Sometimes having less leads to a more positive user experience

So there you have it, four all-too-common mistakes to avoid when it comes to UI design, and how you can stop them dragging down your iOS app.

Good UI design creates a connection to your user gives them a pleasant, effortless experience using your app. This can mean the difference between an app that’s a positive investment for your business, drawing in and retaining customers, or a flop that you’ll write off when it becomes too much of a pain to maintain.

Want to avoid more mistakes in iOS development? The BrightDigit newsletter gives you regular helpful tips and advice right to your inbox!

A couple of times a month, I publish a newsletter, with news, updates, and other content related to Apple and iOS. I try to help people better understand how to succeed with iOS apps, and keep you informed about what’s coming up on the horizon for the industry.

If that’s something you want more of, click here to subscribe, and enjoy!

The challenge is that Apple isn’t always completely clear about the Review process. You would think Apple would want greater clarity on its Store, but given the complexity of all the different kinds of apps in the Store, it’s impossible to not have exceptions or at least grey areas where it’s not clear which rules might apply.

Here are four tips to help you avoid some of the trickiest things that might come up in a Store Review.

Set Up Your In-App Purchases

It shouldn’t come as any surprise, but Apple is quite particular about the use of In-App Purchases. They are, after all, how Apple makes money.

For your first-ever Store Review, your In-App Purchases must be complete and integrated into the app. Not having them complete, up-to-date, and clear about what the customer is paying for is essentially going to guarantee your app will be rejected or declared incomplete.

What usually trips up a lot of developers is that the Store Review is not just a quality check on your app’s functionality and usability – it is also an assessment of the validity of your business model. If the reviewer can’t easily discern what your model is, they’re not going to pass you.

You should include an explanation of your In-App Purchases in your App Review Notes, including any supporting documentation that might be needed. This includes things like purchase icons, screenshots, and what will be visible in an app preview.

If You Want To Use Auto-Renewing Subscriptions…

There isn’t a lot that needs to be said about this, only that if your app offers auto-renewing, in-app subscriptions, Apple requires you to provide ongoing value to subscribed users.

This means that you need to be regularly delivering new content, updates, features, or services to these users. Apple is pretty flexible about what qualifies as ongoing value, only that it must be there, and users should be able to access it without needing to perform additional tasks (i.e. they don’t need to download anything, rate the app, etc.).

Be Careful About Your Use of Copyrighted Content

Legal copyright issues are often one of the things that catch out developers when it comes to content on their apps. This isn’t strictly a problem with Apple: copyright law has a lot of grey areas, and often doesn’t become clearer until someone gets sued.

Apple’s official line is:

*Don’t use protected third-party material such as trademarks, copyrighted works, or patented ideas in your app without permission, and don’t include misleading, false, or copycat representations, names, or metadata in your app bundle or developer name.* Apple App Store Review Guidelines - 5.2.1 Intellectual > Property

What commonly happens is an app will get rejected or delayed because it uses content – usually videos, pictures, music, or literature – that is not owned by the developer.

Be sure to include, when submitting your app for review, that you have documentation that shows that you are either the owner of the content in your app, or that shows you have permission from the copyright owner to use their content in your app. That last little bit might be a little hazy, as there are a wide array of different copyright permissions you can be authorized for (and these might change depending on your legal jurisdiction), so be sure to read the fine print before you submit your app for review. That said, this is not legal advice, and you should consult with a lawyer if you have questions or aren’t sure about something.

Make Sure You’re Using the “Right” 3rd-Party Plugins & Libraries

Along with copyrighted material, Apple is also strict about what libraries and plugins you can use in your app. You are responsible that everything in your app, including third-party services, complies with Apple’s guidelines.

This is especially true if you’re using analytics libraries. The principal reason is their concern for data security and privacy. Apple recently updated its guidance regarding data privacy. I recommend you give it a read, but some notable highlights include:

• If your app is collecting any data from your users, you need to provide a detailed explanation of what data is being collected and how, and all the ways you’re going to use that data.
• If you’re collecting data, you must have the consent of the user, and there will be no tolerance for coercing consent for unnecessary data collection.
• You may only request data collection if you can show that the data is relevant to the core functionality of your app

Something that gets overlooked is that in the case of very popular third-party services there may be multiple libraries of them, including many that might use “hacks” to get the data you want.

In many cases, only the use of the service provider-approved version will pass the Store Review. For example, you might want to use embedded YouTube videos, for which you might be able to find several libraries that facilitate them, and while you might find one that perfectly fits your needs, there is only one approved YouTube library (that is also assured to comply) that will be allowed to pass the Review.

Don’t Try to Cheat Apple – There’s Probably A Better Way

You might remember the controversy surrounding the Hey app, that made industry headlines last year trying to get around the normal 30% cut that Apple takes from In-App purchases. Without going through the entire story Hey tried to avoid paying Apple by declaring itself a reader app like Netflix or Spotify (it’s an email service), and Apple (eventually) said no. After that, Basecamp, Hey’s developer, added a feature allowing for free randomized temporary email addresses that you could get through the app, which appears to have satisfied Apple.

Regardless of the way you stand in the debate, the takeaway is it’s a losing fight to try to cheat Apple (unless you’re just looking for publicity or have a squad of lawyers backing you up). But, if you’re confronted with a dispute with them, there may well be a creative solution to your problem.

In this episode, Leo chats with Paweł Madej, pharmacist turned iOS developer on his learning experience and what pitfalls devs should know about App Store reviews. We talk about what he learned during the submission process of his app CodeConf, as well as the major App Store stories of the year: Hey, Wordpress, xCloud and of course Fortnite.

What are your experiences with App Store Reviews?

So there you have it, five things that you should know before submitting your app for an App Store Review. Do you have any uncommon or little-known challenges you’ve had trying to get your app through the Store Review? I’d love to hear your stories -- feel free to email them, or reach out to me on social media.

Was this useful? Sign up today for the BrightDigit newsletter for more helpful tips!

I put out a newsletter twice a month, where I write about Apple, iOS and iOS-related content and news. I aim to make sure you know what’s going on in the rapidly changing world of Apple. If you want to join them, click here to subscribe, and enjoy!

This can introduce risk and uncertainty. However, it’s an opportunity to ensure your users are getting the best experience possible from your app. Over a long enough time, every app needs to be upgraded, whether to support the newer versions of iOS or take advantage of the latest features., Unfortunately, because the process is so often difficult, headache-inducing, and complicated, it is rarely looked forward to, and often avoided.

It is true that app upgrades aren’t easy. But they don't need to be painful if you plan ahead and make some key decisions of how to approach the process.

To help people who maintain iOS apps, particularly product managers, I’ve put together this small introductory guide to this dirty job of iOS development.

This will cover the factors you’ll want to weigh when deciding:

• Whether to upgrade your app or build a new one
• Where to start the upgrade process
• What refactoring strategy to use
• …as well as other useful tips to keep in mind

Should you upgrade your iOS app?

The most common benefit of refactoring code, as opposed to tossing it all out, is cost. Unless your app is ancient, so badly written the code makes your eyes bleed, or your business needs for the app have fundamentally changed, it’s likely going to be more cost-effective to refactor than to start from scratch.

On the other hand, the one significant downside to refactoring is how time-intensive it can be. If the old code was well-written, appropriately documented, and has a minimal number of pre-existing bugs, there’s a risk rewriting it will introduce new bugs. Therefore refactoring would be a better option - at least for now.

Start with Unit Tests

So you’re committed to upgrading your old iOS app, where do you start?

To make it as easy as possible to maintain and avoid a massive headache for yourself later on, you’re going to want to start by writing the unit tests you need.

This is the core principle of Test-Driven Development (TDD). The idea is, by writing tests first, you create a strong foundation for the code that you can build on as you progress. Here are the basics for unit testing, in case you are unsure:

• You write a unit test describing one piece of functionality of the app
• You will run the test, which should fail because the refactored code to make it work hasn’t been written yet.
• You write and refactor the least amount of code possible to pass the unit test
• Repeat until you have enough test coverage for what you need

The biggest benefits of this approach:

• Practically guarantees **you’re always working in the right direction** when refactoring code
• Reduces the possibility of there being any bugs or errors in the refactored app
• Over the long term, it can drastically **reduce the amount of time and effort** needed as the project progresses
• This approach also encourages developers to have **healthy, effective habits of building good software** architecture.

transisitor https://share.transistor.fm/s/eddb8632

Refactoring Strategies for Upgrading iOS Apps

Broadly speaking, there are two effective strategies for refactoring code as part of an upgrade:

The first strategy is to incrementally write and implement new code alongside old code, effectively working side-by-side until the new code is developed enough to manage all the functionality the old code did. For example, when refactoring an app originally built using UIKit to use SwiftUI, you can use UIViewRepresentable and UIViewControllerRepresentable or UIHostingController to interface between new and old code.

• For using a SwiftUI View inside a UIKit View use:
  • UIHostingController
  • For using a UIView from UIKit inside a SwiftUI View use:
  • UIViewRepresentable
  • For using a UIViewController from UIKit inside a SwiftUI View use
  • UIViewControllerRepresentable

If you are upgrading an older app written in Objective-C – that you are upgrading to use code written in Swift – you can use Swift bridging, which will keep the Objective-C code working as you implement the new code structure necessary for Swift. If you still need to write Objective-C to bridge that gap, I'd recommend our article on writing Swift-friendly Objective-C code. If your app falls into this category, this is something you probably should be considering, as Apple has made it pretty clear that it everything new in its software ecosystem will be exclusively Swift.

The second strategy uses failure as an active tool to both discover and implement new code. Rather than trying to sustain the old code while creating the new, you start by aiming to have the new code immediately replace the old as the project progresses

This should result in code regularly failing to compile. However, by actively failing, you are able to rapidly discover what is and is not working, and focus on writing code for what is broken.

Which strategy should you use?

Now, you might ask yourself, which technique should I use? The simple answer, as is often the case with software, is it depends. Both are perfectly valid, at depending on the nature of the code, there may come a point where you end up using both.

The side-by-side bridging strategy has the advantage of being able to seamlessly integrate new code with the old over time on a live app. The reason being that your users might not even notice a difference in functionality. The result is a stable, consistent process that allows you to control when big changes are needed

On the other hand, the break and replace strategy will quickly reveal the most important parts of the code you need to refactor, getting right down to the root of any dirty code or code smells that might exist.

However, if your app has a lot of complicated code, you might find a break and replace strategy is even more time-consuming. It will potentially force you to pull out very large sections of code that will need to be entirely rebuilt before they can be deployed. That said, if your developers retain a history of the code, this could be done relatively quickly. Having been working with the code for a long time, they can then be very focused on what they are looking for and what will need to be refactored.

More Tips For Upgrading Your App

Have rules, be consistent with them

Having rules when coding is important – this goes doubly when refactoring. If you’re going to have a lot of people working on your code, make sure everyone has a shared understanding of how things are to be done, recorded, and tracked throughout the project.

As an example, I like to ask other developers whether they use tabs vs. spaces in their code. Every developer of any significant experience will prefer one or the other. It’s a small, but important rule that you want to make sure all the developers working on your app are aligned with, as it can affect the code quality of the app’s software architecture overall. Other things you’ll want to establish rules for include how new code is integrated into the app, for which I recommend using continuous integration techniques.

Have a Clear, Consistent System for Bug Tracking

Like any good software project, but particularly important when upgrading an iOS app is having a clear process for bug tracking. I’ve previously written about tracking bugs and error handling in Swift here. There are many tools and services available, including a few online services that are great for tracking bugs and log statements, such as:

• Bugsnag
• Firebase Crashlytics
• Instabug

As a small side note: there is a good case to be made, for apps running on iOS 14 and later, to make use of OSLog. If you’re not familiar, it’s a handy library for logging messages to the console. It’s particularly useful for being able to filter out categories of app logs within the console app when compiling code as well.

Avoid 3rd Party Dependencies

While bug trackers can be a valid 3rd party dependency, there are many which you should avoid if you can. Every time you use a new dependency in your app, you’re exposing it to the risk of bugs or outright failure if the 3rd party ever decides to shut down or has not been properly upgraded and maintained themselves.

If you are going to use a 3rd-party library or tool, make sure you spend time weighing the costs to your app should it fail against the benefits it gives.

In this second part of our interview with Antoine van der Lee, we talk about how to upgrade older apps piecemeal, supporting older OSes, as well as bug tracking and logging.

Upgrading can be a great way to give an old app a new life

Upgrading an older app through refactoring and rewriting code can be a cost-effective way of ensuring continued, stable performance and for your users. Like restoring anything though, it’s important to be patient, as you’re likely to encounter obstacles that are difficult to anticipate.

Begin by deciding how much value the app offers and how much time you have to undertake the upgrade. If you’re sure this is right for your app, begin with a test-driven development strategy that ensures your progress will be consistent, and easy to maintain after the upgrade is complete.

Decide whether slow bridging refactor or a break and replace strategy is most appropriate for you. You can figure this out by considering:

• what is needed from the app
• how much time you have available
• how complicated your app is
• and most importantly, how much knowledge your development team has of the history of the code

Finally, make sure to always have clear, consistent rules for coding and refactoring, especially for complex apps and where you have many people working on the app. Be sure to have a reliable way to log and track bugs, and, within reason, avoid relying on 3rd party dependencies.

Tell me more about your iOS app

Do you have an iOS app that you are upgrading, or planning to upgrade? Do you want to learn more about the process? I’d like to know and answer any questions you might have. I offer some free consulting time each month for companies that are serious about moving their iOS app projects forward and are looking for help or guidance. To book a free consultation call with me, go here and book an appointment. I look forward to hearing from you and learning more about your app!

Remote work in software development isn’t anything new. Just ask those with experience in distributed software development.

There are some important lessons we’ve learned over the years on how to do work remotely well. There are benefits that help both employees and employers. I’ll go through the most important best practices you’re going to want to put in place. This will ensure remote work supports your capacity to build great iOS apps without slowing everything down.

The Benefits of Remote Working

As an independent developer, I have a bias for remote work – I’ve been working remotely for almost 10 years. I’ve noticed major benefits:

• Dealing with Home Life - It makes it easier to adapt to changing circumstances in your work and home life. If a project you’re working on needs your attention unexpectedly, or one of your children is home from school sick, it's much easier to adapt with everything you need within easy reach.

• Saving Time and Money - Working from home saves an enormous amount of time and money that you may not be aware of until you try it. It is estimated that, before COVID-19, the average American was spending 225 hours a year – more than nine calendar days – commuting. As well, the cost of car maintenance and/or public transit adds up to thousands of dollars each year. And that’s to say nothing of what other things you could be doing for your work or life with that time.

• Reducing Overhead - It reduces overhead and productivity loss from commuting and needing an office to accommodate all your staff all the time. There is data that shows that, if management has a positive, trusting relationship with their staff, remote work can give employees a significant productivity boost.

• Improved Flexibility - Remote working can also make the business more competitive. First, the flexibility of remote work makes it easier for employees to deliver their best work and for employers to retain them. As well, remote working usually forces a shift toward focusing on whether goals are being met, and away from performance being judged by mere presence in the office.

Some of these benefits are hampered by the fact that remote working needed to be implemented quickly. This is further compounded by complications like healthcare, loss of business, and having kids remote learning from home. However, we can reasonably expect it to get easier.

Working Remotely Best Practices for iOS Development

Get Buy-in

This should be obvious to most people, but with the regular failure of workplace transformations, the realization that the much-vaunted open-plan office did the opposite of what it was sold to do, and the additional analysis that shows such offices are excellent vectors of disease, it bears repeating. If you’re a manager, keen to implement remote work for your team, you need to make the change collaborative. If you want your developers to be effective with a remote work policy, have them be a part in creating it. 

The pandemic imposed this way of work on millions in a way that they never got to have a say in, let alone prepare for.

iOS App Provisioning

App Provisioning is probably the single most important Apple-specific consideration when it comes to remote work. Apple has a chain of authority between itself and your app. This chain is designed to make sure your app is trustworthy and stable before being downloadable from the App Store. Apple doesn’t make it especially easy to understand how it works.

A Brief (as possible) explanation of iOS App Provisioning

First, there is the Apple Certificate Authority. It serves as the gatekeeper to the App Store.

When you start building an iOS app, you create a Signing Certificate. This identifies you as a developer recognized by Apple. Creating a Signing Certificate generates a key on your computer (and only your computer) that connects you to the Apple Certificate Authority.

With that done, the iOS app you’re creating is assigned an App ID, linking your app to your Signing Certificate.

Next, you must create Provisioning Profiles. These profiles declare connections between a specific build of your app and the App ID. Each profile specifies what that build is for (i.e. internal development, adhoc distribution, release to the App Store). It may also contain a list of devices where the app can be tested and distributed.

Now, why does this all matter if you want to work remotely? Because to make this work, you’re going to need to determine, for every member of your development team, who has what access to a specific provision profile, and on which machines (both in the work office and the remote office). You'll also need to decide who handles the computer with the Signing Certificate key.

It’s not especially difficult to manage once it’s done, but expect it to be a time-consuming task to set up.

I highly recommend taking a look at the Fastlane suite and their Match command to help streamline this. Also here's a great list of tech articles to help with this:

• DEMYSTIFYING IOS PROVISIONING By Cory Bohon
• What is a provisioning profile & code signing in iOS? by Abhimuralidharan

Communication

Successful remote work is almost entirely about communication. Critically, the style of communication needed for effective remote work is different from those that are successful when everyone is together. You need a different set of rules and tools for remote work communication:

Choose your tools

For many teams, there is likely already an answer to the question of what tool they want to use for communication because they’re already using one. Slack is far and away the most popular. MS Teams and Chanty are also proven and effective platforms. There are many different tools and platforms available depending on how many people are involved and the details of what they need.

Choose your communication rules

In an office, people pick up on what are usually unwritten rules of communication through context and observation. This is obviously much more difficult when your colleagues only appear as names on a screen.

To keep things running smoothly, make rules written and explicit.

• How often should you reasonably wait for a response during work hours?
• And work hours in which timezone?
• With many channels, what information do you put in which channel?
• If there are important announcements, how are those delivered?

These are just some questions for which the answers should rules or guidelines.

With asynchronous communication, you need to be open to learning new communication habits. You will need a different attitude than you do at the office. People will not always message you back right away. If you need to talk to someone about something important, schedule a meeting.

For more details on how to communicate remotely, we did a podcast episode on this very topic. We talked with Jacob Gorban who has been leading remote work for over 10 years at his company Apparent Software. Not only do we talk about communication, but also keeping teams productive, managing iOS development and more.

Training/Code Review Planning

You will want a remote work-specific process for code review and feedback, especially for junior developers who need mentoring. How you handle this up to you: you might schedule meetings between senior developers and juniors, or even (when conditions allow) having them meet at the office.

Working Remotely Doesn’t Work For Everyone

There are some conditions where remote work probably isn’t an optimal policy. Much like getting buy-in, involving everyone and discussing how remote work might work should reveal if it’s a good idea. That said, there are cases where it can often be unhelpful:

• Unstable or rapidly changing workflow Remote work usually succeeds when the workflow is stable and consistent (even if there are rapid changes within the project itself). If the workflow is constantly shifting, remote work can work, but you’re probably going to discover you will need to bring everyone together often to ensure they’re all on the same page.

• Inexperienced teams or very old teams Remote work tends to work best with teams that already know and understand each other well. If team members are working with each other for the first time, there is no reason they shouldn’t be able to work remotely, but they should have opportunities to work together to build better rapport.

On the other hand, teams that have been together for a long time, and have up until this point only worked together in the same space, might find remote work challenging if it goes against the grain of how they’ve always worked together before.

None of this should be considered a universal rule, only that it shouldn’t be surprising if teams like these find remote work to be difficult.

Getting started with working remotely

To make remote work iOS development a successful practice, you do need to put in the work up front. A lot of it is communication-related, with some technical. Done effectively, it can be a powerful tool for your organization. It can help you develop better apps faster, and with less overhead and friction than when working together in an office.

Was this useful to you? You can get more helpful advice like with the BrightDigit newsletter

I put together a newsletter twice a month, where I deliver iOS and iOS-related content and news. I aim to make sure that my subscribers are always on the leading edge of knowing what’s going on in the rapidly changing world of iOS and Apple. If you want to join them, click here to subscribe, and enjoy!

There will always be errors you do not expect. As developers, we want as much information about how and why something failed to either make the best possible change to the code or to help the user respond. However, what is most helpful for the developer is not always so helpful for the user, which is critical to understand if you want a successful app.

This article is designed to help both developers and team managers:

• create a plan for dealing with errors; and
• offer examples of how to effectively handle the most common errors you’ll encounter.

Successful Swift Error Handling Always Starts With A Plan

If you’re on a team that manages an app’s codebase, or are the manager of that team, you need to have an effective plan for dealing with errors. Not having a plan, or having a plan not clearly understood by everyone, is going to needlessly create more work for everyone, and you’ll find it difficult to deliver a consistent and satisfying experience to your users.

An effective error handling plan for a Swift-built app should include:

• Recording and Tracking Errors You need a tool that records and tracks errors. Crashlytics and Bugsnag are two popular ones. Beyond that, you should have some kind of internal process on the team level for acknowledging, assigning, and reviewing errors, so that they don’t use up more team resources than necessary to address.
• Error Testing If you expect an error and crash, you should test for those in your unit tests. While XCTest provides ways to test for errors, crashes take a little bit of work.

I’d recommend taking a look at the links on our Error Handling episode with Jeff Kelley or his presentation from 360iDev.

A successful testing approach for Swift should then include this functionality, allowing you to be able to proactively fix and, more importantly, anticipate and accommodate expected errors.

* Communicating With Users
This last part is essential to delivering a quality user experience. So many apps that experience errors do an inadequate job of communicating to the user how and why an error occurs, or what the user might be able to do to avoid the error in the future. A successful error handling plan should include an approach to using UI tools to inform and help your user when they experience an error using your app.

That last part of the plan, clearly communicating with and engaging your user in the event of an error, can be very challenging. To help, I’ve got examples of three of the most common types of errors you’ll likely encounter, and how to engage your users when they happen.

Networking Errors – Don’t Overwhelm Your User

Network errors are likely to be the most common type of error when developing an app with Swift. Most iOS apps, or apps of any kind for that matter, have networking as a core part of their functionality.

As a preventative measure, you want some sort of indication built into your app that there is network connectivity, especially if something is in progress. For example, if the app is transferring data, you should make that clear to your user and warn them not to disconnect.

Networking errors are a good example of the kind of error where you’ll likely need your user to take action. If your app tries to connect and the network is unavailable, use a dialogue screen explaining to your user that the app has failed due to inadequate connectivity. For a superior user experience, give the user the option to try and connect again, if possible.

But, as anyone that has ever coded a try again button knows, this can be difficult to do depending if your network architecture isn’t separate from your app UI (common in most modern apps). The error and information explaining why it happened need to be raised to a point where the user can respond, which can be tricky to determine.

What is critical is considering how much detail about the network error you want to relay to the user. While the error number and data are useful for a developer, that much information is going to be overwhelming to a non-technical user. As a rule, if the information is not relevant to the user experience, it should be hidden from the user.

Permissions – An Informed User is a Happy User

Building on communicating effectively with your user, sometimes you’ll have errors that require your user to make decisions to get the app working again. Apple’s system for accessing Protected Resources is a source of great examples of this scenario.

Even if you’re not intimately familiar with this aspect of the Apple ecosystem, it’s easy enough to understand: our phones and devices have a lot of sensitive information about us on them these days; Many apps use this data to help their users; This includes location information, your photos, and access to the camera itself, among other things. These are known as Protected Resources.

Because not all apps need access to them, by default Apple restricts access to Protected Resources. If an app needs a Protected Resource to carry out a function and doesn’t have access, this will create an error. To gain access, an app must make a case request, with an explanation of why it needs permission to use certain data or hardware functions. The user then decides whether to give permission to the app or not.

There are two key considerations when dealing with permissions. The first is making it clear to the user why the app needs access to a given Protected Resource. Apple itself is explicit about this:

Accurately and concisely explaining to the user why your app needsaccess to sensitive data, typically in one complete sentence, lets theuser make an informed decision and improves the chances that they’llgrant access.

Having an easy-to-understand explanation then is not only needed, it makes for a better user experience and ultimately, a more successful app.

The second consideration is deciding how to handle the user denying permission. Again, clear communication to the user about the limitations of the app’s functionality if denied access is helpful. You also must decide, on a code level, how to deal with the persistent error of denied permission.

Ideally, you want the user to still be able to use the app, even if certain data or functions are not available. At the same time, it’s important to continue to make it clear that if a user wants to do something that needs a Protected Resource, they have to go into their settings and grant permission.

A stumbling block to be aware of is in some cases there isn’t (yet) a way of telling the difference between a lack of access and a lack of input. A good example of this is heart rate monitoring: an app may experience an error because it can’t collect data on a user’s heart rate, but isn’t able to report whether this is because of a lack of permission or because the heart rate sensor on the device isn’t working.

If you’re using health data, this is something to be aware of.

Missing Files – How to Fail Gracefully

While many errors are recoverable with some help from the user, sometimes there are errors that can happen, and will be fatal. How should you handle these?

Ideally, you want to handle these errors as cleanly and gracefully as possible. Missing files are a common example of this – when your app can’t find or access a key resource it needs to function, like a storyboard file, an image, a database, or a key piece of code. The app needs to close and a bug report sent to the developer to review the error and make fixes.

Indicate to the user that something has gone seriously wrong and the app needs to shut down. Perhaps offer them a button to close the app and assure them that a bug report has been sent. You can also let them know if it’s not just a glitch or the user has tampered with the app.

iOS Development is unpredictable

Building a complex iOS app is inherently unpredictable. You usually start a project with not much more than:

• a broad vision for the work,
• a list of feature requirements,
• and what problem the app needs to solve for the user.

No one can accurately predict what the app will be like when it’s done.

There will be obstacles that arise that you only discover when you start publishing the app. Additionally, it’s likely the client will change their requirements. Moreover, there could be a major change to a library halfway through the project. As a result, your team will need to rethink the app going forward.

Tried and True iOS Team Management?

This is fundamentally different from older, more established kinds of work. For instance, with accounting, we’ve been managing money for the entire history of human civilization. The work is governed by well-established rules, regulations, and best practices. For this reason, there is generally an established way to achieve a desired result if the accounting is done well.

By comparison, iOS development is not even 15 years old. As a result, it has very few rules and best practices. In effect, there are multiple ways to a given result, each with pros and cons.

What Does This Have To Do With Management?

To manage this unpredictability, good iOS development teams are collaborative. Members need to be able to:

• flexibly share thoughts and ideas.
• work together to solve unexpected problems.
• not be constrained by a single way of approaching a specific problem.

This goes beyond building the app. It is not unusual for an unforeseen change in the codebase, user behavior, or the client’s business to destabilize an app. Most likely this will result in needing an update or additional maintenance.

Having a single person with an opinion (ie a manager or executive) who dictates how the app will be built becomes an obstacle to maintaining the best app possible. This is regardless of how much that manager or leader might know about software or how well-meaning they might be.

Encouraging Your Team

Managers aren’t going to go away – they almost always serve a key role in their organizations. The question is then: How can we reconcile management and iOS development? How might a manager work with a team, guiding and supporting their collaborative capacity? At the same time, how can a manager avoid tilting the team’s decisions with their influence?

What I’ve found is that the best iOS managers share a few traits. These traits:

• help them build up and support their teams,
• help them work without becoming controlling,
• and balance the unpredictability of development work with the stability most businesses and organizations need.

What follows are three traits that the most amazing iOS managers I've worked with have shared.

They Are Great Listeners

There’s a tactic I’ve seen some managers use: when the team is working through something together, they make sure they are always the last one to speak. They don’t want to influence the opinions of the team before they’ve had a chance to hear each other. As Peter Witham noted in my recent interview with him on my EmpowerApps.Show, it also gives the manager time to carefully listen and consider how the team thinks and feels before they weigh in.

How Peter Witham gets feedback as a manager from
Episode 29 of Empower Apps

It really can’t be underestimated how powerful it is to listen to the people you manage while resisting the urge to intervene, even if you feel strongly about the best way forward. Rather than an emphasis on control, assigning responsibility, and motivating the team – valued by traditional management – a good iOS manager sits back and listens.

Listening to your team

Along with a bit of empathy, this can do wonders. Not only for your team’s ability to organize its work and deliver it, but it also boosts the confidence of team members. As a result, this will encourage them to take on difficult challenges. Additionally, they are free to learn from those challenges, knowing they are supported by their boss.

For instance, the team may be building an application that requires an Apple Watch component. How should that application synchronize with the iPhone app? Should the app be independent? Are watch complications worth the effort implementing? A manager may decide whatever the simplest solution that will save time and money is best. However, a more experienced developer with the Apple Watch knows the benefits and risks of different approaches:

• WatchConnectivity vs. Networking?
• Independent vs. Dependent App?
• Complications or App Only?

That said, the manager still has an authoritative role. They are still responsible for deciding work priorities, as well as mediating relationships, specifically the relationship between app development and its value to the business. Part of that role includes setting boundaries on what is possible whether due to money or time. However, by taking a listening approach, rather than controlling and assigning, the team can easily address these limits as they do with any other limitation they have in building an app.

They Welcome And Invite Challenges From The Team

If a manager is committed to empathizing with their iOS development team, they must be open to having their mind changed. To that end, they must be able to entertain ideas or approaches that may not have initially occurred to them.

However, the best managers invite these kinds of challenges. An iOS manager is just as likely to miss things in the code, make bad calls, and screw up as anyone.

The goal is to make team members feel safe expressing themselves. Especially if they challenge the opinions, ideas, and decisions of their manager. And critically, when they feel the manager's opinions aren’t serving the best interests of the team or the project.

Understanding Your Options

For instance, choosing a backend can be especially challenging. I have even written a whole blog post on the different choices. In many cases, Firebase is the default choice. However, there are caveats that an opposing developer should present. While it could change the resulting backend, at the very least it makes the team aware of other challenges ahead.

There is more for a manager that is both capable of putting aside their ego (a challenging task in almost any work environment) and feels strongly about what should be done. Namely, they need to share their thoughts while actively asking the team to shoot them down. 

The benefit of this is not only making the team feel comfortable with asserting itself but also it ensures someone will walk away from the interaction having learned something.

They actively support multiple solutions to problems

Naturally following from being open to challenges and the questioning of ideas, supportive iOS managers help their team develop the capacity for multiple solutions. Most importantly, those solutions should be for persistent issues or obstacles they encounter during development.

One of the features of iOS development is how quickly everything changes. That is to say, what your iOS development team knows now could be less important in five years.

Building For Now... and For The Future

As an example, we have seen over the last five years the replacement of Objective-C with Swift as the preeminent language for native iOS development. For macOS developers, we are seeing a distinct shift toward Catalyst and away from AppKit. And most importantly, we see SwiftUI along with its patterns overtaking the paradigm Apple previously encouraged with UIKit within the Apple ecosystem.

A good iOS manager needs to support team efforts to compensate for these rapid changes. Not only in building the app today but also to help them stay ahead of the curve.

What can you concretely do as a manager? Although it may come at the somewhat difficult sacrifice of short-term efficiency, you need to give your team the time and space to try new things and experiment.

This can be as simple as leaving time in the workweek. Give team members time to learn new tools, libraries, or APIs when they come out. Additionally, you could also encourage them to create side projects and showcase them to demonstrate the potential of new approaches. Over time, it helps the team adapt faster as new things come out and the nature of apps changes.

I want to help people build better iOS apps

I hope the above is helpful for you if you’re managing an iOS team and want to help them become more effective and valuable to your business. You don’t need to change your entire management style overnight. However, I think if you can work on any of these traits, the results will speak for themselves. You will end up with a happier, more effective team that makes better apps that delight customers.

While you’re here, I’d like to invite you to sign up for my newsletter, where I share advice and tips like what you’ve just read to help businesses and agencies improve the quality of their iOS development. Just click here and leave me your name and email. Thanks!

This is a big deal for Apple app developers – the new hardware and software offer new features that significantly raise the bar for what is possible with the Watch. Apple has given us the tools to create more sophisticated kinds of apps, both standalone for the Watch, as well as companions for iOS.

By far the most important addition with WatchOS 7 is the newly enabled ability to build complications (i.e. watch face elements) using SwiftUI. This opens up all kinds of possibilities for how we can show information to users. There were also some great new service additions with the Family Setup and Fitness+. Finally, on the hardware side, the new blood oxygen sensor in the new Watch opens up opportunities for new apps, particularly in the health and fitness segment.

I’ll be covering a general overview of these new features, then dive into what app developers can do to take advantage of this new release, and what I think they should consider offering to their customers.

Watch Faces Are Now More Complicated… and that’s a good thing.

The most interesting part of the new Apple Watch Series 6 release is the power to create watch face complications using SwiftUI. Along with newly added complications, this expands what we can put on the watch face. It also makes the work of creating face customizations quicker and easier.

SwiftUI complications remove the difficulties we’ve had building custom elements for Watch apps or Watch companions to iOS apps. This is especially noticeable with navigation bars. Particularly, SwiftUI can now be used to build dynamic navigation bars, the same as with any other Apple platform. Even better, you can now code these elements and reuse them, something that was painful about building apps on earlier versions of the Watch.

For more information on SwiftUI, check out our SwiftUI articles here.

The complications themselves are also more refined with SwiftUI. SwiftUI can make use of the same tools we use to code other Apple apps. This includes the ability to customize templates that already existed in SwiftUI, but weren’t usable before now for the Watch. You can now also have more than one complication and watch face for an app. This has been a serious barrier before now to making more complex software. We also have more watch faces to choose from, with Apple pointing to the new Stripes, Chronograph, and Artist faces, giving more options for what we can render in a watch app.

New Blood Oxygen Sensor

The sensor on the Series 6 Watches that measures blood oxygen levels is a great addition, particularly for developers that build apps for clients in the healthcare and fitness industry. The way it works is pretty straightforward – the sensor measures the oxygen saturation levels using LEDs built into the back of the Watch.

What’s also worth considering is what’s not here (yet). The introduction of the blood oxygen sensor speaks to increasing sophistication in the Watch’s hardware, which may mean even more impressive things are to come.

For instance, what if the Series 7 Watches could help detect blood sugar levels? Then we could build apps that could assist the millions of diabetics in the world – with a watch – and transform the way they manage their own health. Again, we’re not there yet, but with this technology improving by leaps and bounds, it may be here soon.

Even more from Apple Watch Series 6?

The new Apple Watch Series 6 and has a couple of other things worth briefly noting:

Family Setup

Family Setup is a system that allows multiple Watches to connect to a single iPhone. Apple sells this with the idea that kids can communicate with their parents through the Watch, while parents can keep track of where their kids are and send them reminders.

Hardware Performance

Overall, Series 6 is a nice improvement over its predecessors in terms of power and performance. It features a new CPU, the S6, making everything run faster. While the battery hasn’t improved like we were hoping, it maintains 18 hours of battery life despite hardware upgrades and now includes fast-charging capability.

So, what does this all mean?

Several months back, I’d said that while the Apple Watch was good, it needed more improvements before it deserved great investment. With the exception of battery life, this new release demonstrates the maturity of the platform – it’s ready to stop being a curiosity worn only by early adopters and tech enthusiasts, and into something that most public consumers could benefit from having. The Apple Watch, in short, has arrived.

The Apple Watch SE will also likely contribute to bringing more users into the fold with a smaller price tag while not skimping on performance. The SE models have the same size display, while only really compromising by not having an always-on display, the newest sensors found on the Series 6 (like the blood oxygen sensor), and limits on available colours and materials.I would anticipate at least a few people go in for this, especially first-time buyers of Apple Watches or Apple products generally.

This means now is the perfect time to build an app for the Apple Watch or a companion app for iOS. Doing so has never been easier, both to build the app and to integrate it with other Apple devices. Getting started now also means getting ahead of the curve, so by the time Series 7 is released, which will likely be a refinement of the major changes delivered this year, you can take full advantage of the latest Apple has to offer.

What Can You Do Now?

Since there’s such a wide range of things you do with the new Watch, rather than try to wade through the technical possibilities, I’ve got three examples of apps that can be made with the new Watch that was not possible with older models/OS versions:

Pizza Delivery

This was a great idea that my recent guest to my podcast, Steve Lipton, casually mentioned. I think it makes a great example of a companion app that could make use of multiple complications and watch faces.

I made an order form on a watch to order a pizza. In reality, that's not something that people will be doing is sitting there, scrolling away, trying to hit buttons. They'll do that on their phones. Instead, what they'll do is look at their watch and know where when the delivery time is going to be. Steve Lipton - Episode 63

First off, given its size, you’re not likely going to enjoy trying to order a pizza on the Watch (with maybe the exception of a repeat order that the app remembered) —You’ll still be wanting an iPhone or iPad. Once the order is made, however, the companion app could tell the customer, with a glance at their wrist:

• the status of their order
• how long until delivery arrives
• a map showing the delivery driver’s progress
• even a message alert from the driver

Sports Tracking App

This takes advantage of the new multiple complications and watch faces. This app could conveniently let the user know the stats of, say, an ongoing hockey game while they are out walking their dog. With a single face (perhaps Stripes, Infograph, or Modular) you could have complications showing the time, score, as well as more detailed information like who scored the last goal or is in the penalty box. With WatchOS 7, displaying this relatively large amount of fast-moving data can be achieved relatively painlessly.

Health & Fitness Monitoring App

I would be amiss if I didn’t mention the potential of new health & fitness apps for the Watch, something Apple itself heavily emphasized during the release with its Fitness+ workout service,

With all these new features, you could have a watch-based ‘cardiobot’ that could track, display, and record various statistics related to the user’s heart (heart rate, blood oxygen level, ECG). This could be helpful for someone out for a run focusing on maintaining an optimal heart rate. It could be equally helpful for a more sedentary user, alerting them to make sure they’re drinking enough water, or when it would be a good idea to go out for a walk. It could even alert medical services if it detects an arrhythmia or dangerous slowing of the wearer’s heart.

The new Apple Watch shows a lot of promise

I don’t think there’s been a more exciting time to be looking at developing for the Apple Watch since it first came out. Having a tiny computer on your wrist is a great idea, but it’s taken years to make it convenient, accessible, and worthwhile for both users and developers.

Keep track of the latest in Apple Watch app development

If you want to stay up-to-date on developer-relevant news, advice, and tips about the Watch and other platforms in the Apple ecosystem, I regularly cover this through my newsletter. As a specialist iOS and Apple developer, I’m always looking to the future to see what is coming next and how we can build better apps for our customers.

Just the same, Apple announced, via virtual conference, a lot of things we can feel excited about. Some things have the potential to really shift the way we create software.

Here’s you need to know about what Apple revealed to us about what they’ve been working on.

iOS 14 gives us a lot more smart, a little bit less phone

Far and away, the most exciting announcements from Apple are coming in with iOS 14. WWDC 2020 appears to be the year where having a big screen has become a central issue for iPhone design. Likewise, the iPhone is less about making calls and more about having a small, smart device in your pocket. This is perhaps best demonstrated by phone calls no longer taking up the whole screen when in use (Siri doesn’t either).

Here’s a few other things that are going to matter with iOS 14 that we’ve found in the beta version:

Some of the best ideas come from your competition

With this rethink about what the phone screen is for, Apple offers things that will be familiar to Android users: widgets, app clips, and default app selection.

Widgets

This feature is one Android users have been able to enjoy for years, and now it’s coming to Apple - especially for the iPhone. This makes sense with the purpose of the iPhone being less about making calls. The iPhone has become more of a source of information that you can easily place at. These widgets will come in all kinds of sizes and, will look better than anything we’ve ever had in older iOS versions. Additonally, the iPhone will even be able to stack widgets on the app screen intellegently, based on user behavior and settings.

SwiftUI continues to improve at WWDC 2020

SwiftUI is now a year old. And at WWDC 2020 they announced new improvements and additions for the new releases. You can build an entire app now within SwiftUI, without needing to resort to any of the older APIs. With the introduction of widgets and build complications, Apple made WidgetKit available only via SwiftUI, their API for building Widgets.

If you are interested in learning more about SwiftUI from WWDC 2020, check out our episodes with Majid Jabrayilov on EmpowerApps.Show.

Apple has designed their widgets to be flexible and compatible across all their devices. So the small widget is conveniently the same size as the standard watchOS interface. While the large version of the same widget could fit comfortably on an iPhone, iPad, or Mac. It’s your choice as a developer in which sizes you want to support. On top of that, Apple enabled the use of “stacks” and “smart stacks”. These "stacks" allow you to layer different widgets over each other and order them according to user preference and behavior.

App Clips

Another smart idea that is coming over from the Android world is App Clips. App Clips are basically “previews” of full apps. They enable you to quickly download and temporarily check out an app. For instance, you want to try a new food delivery app. You may not want to compare it against the one you already have. Additionally, you may only use the app one instance and never need it again. You can use the App Clip to try it out and decide if you want to keep it. This reduces cluttering up your phone app screens and data storage.

Default Apps

It boggles the mind that we’ve never been able to choose which app runs by default when opening files or doing routine tasks on the iPhone (something that Android and Mac users take for granted). Now we will on iOS 14, and that can only be a good thing, for developers and consumers alike.

Apple Silicon: New chips for a new era for the Mac

After years of using Intel-built processors for the Mac, Apple is transitioning to using their own Apple Silicon CPUs. This is a monumental shift for Apple. They’ve already demonstrated that these 64-bit ARM-based chips can easily match the speed of comparative Intel chips while drawing less power on other devices.

What we can expect in the next 10-15 years are Macs that have better performance per watt and high-performance GPUs. This is all great news for app developers, especially for those making professional apps and games. While it will take some time for these new chips to roll out, we can expect they’ll be everywhere within two years.

macOS 11 at WWDC 2020

Aside from the new chips, the new version of macOS, known as Big Sur, features a UI redesign. The redesign is in line with the updates I mentioned above with iOS and iPadOS (widgets, better navigation). There’s also changes to Safari Web Extensions, allowing you to set when and where an extension is used in Safari, as opposed to simply being “on” all the time.

If you are interested in learning more about changes to macOS from WWDC 2020, check out our episodes with Lucas Derraugh on EmpowerApps.Show.

After WWDC 2020, Privacy Policy Now A Must-Have

App developers now must include a privacy policy with their apps. Additionally, Apple has gone to a lot of effort to make this clear and concise. I think we can all agree that anything that makes our apps earn more trust from users should always be a high priority.

Amongst other things, users will be able to set how precisely an app can see their location. It will also be clearer how apps use different parts of the hardware, such as the microphone or camera.

iPadOS 14 also seeing some great new features

Much like iOS 14, iPadOS 14 is getting a few nice updates to its features. The ones I think that are worth paying attention to include UI improvements. Most importantly, these introduce sidebars that make the interface navigation much easier to use (similar to macOS), as well as the widgets included on the iPhone. There are also updates to the platform’s LiDAR scanner, which will be helpful for those of developing apps that need to measure distance. Lastly, Apple made a big improvement to the Apple Pencil with Scribble. Scribble has the ability to convert written notes to typed text and recognize basic drawn shapes. This could be amazing for people, who prefer the tactile experience of writing by hand, for notes or marking up documents quickly.

With WWDC 2020, the future of Apple app development looks bright

WWDC is almost always an exciting event, and this year was no exception, despite none of us being able to attend in person. There are some really clear, intelligent changes coming to Apple and its platforms. These changes are going to make building apps faster and easier. They will also open us up to including some great functionality that we’ve never had before.

Is your app ready for these changes?

All of these announcements from WWDC 2020 mean things are changing for how we develop or update apps for the Apple ecosystem. If you're ready to explore what it will take to make your app idea a reality or to update your existing app for this year, contact me to learn how I can help you and get you a free estimate.

At the time of writing, the Apple Watch is coming up on its 5th birthday. The technology has come a long way since it was first released. With the release of its latest operating system, watchOS 6, I believe this is the year the Apple Watch will come into its own. 2020 is when it moves from being a curiosity and a status object to a useful device for everyone.

If you’re thinking about building an app for the Watch, read on: this article is for you. 

I’ll be covering:

• why and how the Apple Watch has improved
• where it still needs improvement
• and what you need to know to decide **if a watch app is a good idea for your business**

Hearts & Minds: What the Apple Watch is good for.

There are two core areas where the Watch can excel: health and location.

With so many of us using our personal data to become fitter and healthier, the Watch represents an opportunity. watchOS 6 makes things a lot easier when creating watch apps that help you measure data about your body: everything from...

• exercise time and speed
• heart rate to your breathing
• sleep patterns
• or menstrual cycle

It’s relatively straightforward to design an app that allows you to input the data via the Watch, as well as have the watch passively record information while you’re active.

Secondly, there is potential to incorporate location-based tools that could be useful for business. It's now easy to imagine your watch tracking shipments and deliveries, or letting your customer know how far away their delivery is on their watch. What if your watch could help you navigate a building you're unfamiliar with, so you know you'll arrive on time for a meeting? In another situation, a nurse could find out where a doctor is in the hospital. It would mean not having to page them because they could see they're seeing a patient or doing surgery.

It’s come a long way, but Apple Watch still has a ways to go.

All that said, there are some things the Watch needs work on before it can flex its complete potential: battery and sensor improvements.

While the battery of Series 3 or later Apple Watches is magnitudes better than what Apple started with, it still runs down faster than I feel most people will find convenient. The always-on display introduced in the last couple of releases, while improving usability, also doesn’t seem to have helped battery usage like Apple hoped it would. With so many apps needing direct connections to the internet – a relatively energy-intensive task – the battery will need to be improved if it’s going to succeed in the long term.

At the same time, while the sensor capabilities the current Watch series are powerful, they can still be less than reliable, notably when it comes to movement and speed. That said, we are still very much in the infancy of wearable technology, so it is reasonable to expect these to improve and new sensors to be added: as an example, for the last few years we’ve seen demos of watches that can help you monitor your blood sugar levels – a boon for diabetics.

Finally, while I’m expecting this to change very soon at the time of writing, Apple has not yet deployed StoreKit to the Watch – the framework we use for functions related to the App Store. This will be necessary if Apple wants to develop the Watch ‘app ecosystem’ and make it easy to deploy, buy, and install apps on the Watch itself.

So you want to build a Watch app?

Businesses and organizations related to areas I’ve covered above, especially health & fitness, are most likely to benefit from the Apple Watch and its new operating system. There are a few considerations I think everyone should take into account before committing to a new app:

Battery usage... again

The first consideration is, what kind of resources will your app need, specifically related to the limitations of the current battery? If your app needs frequent or constant connectivity to the cloud or a server, you may find the results a little disappointing. Your users will likely love the performance of a Watch app but will struggle with how quickly the Watch runs out of juice.

If this is a critical need to serve your customers, my recommendation is to wait perhaps another year for Apple to tackle this challenge and see what hardware improvements they deliver.

Is it going to take a long time to build?

Another thing to think about is how long it will take to build and deploy your new app. With the release of independent Watch apps and (hopefully) the imminent release of StoreKit for the Watch, the Apple development community is expecting a number of important changes and improvements. This may alter the needs or requirements of your app.

To SwiftUI or not to SwiftUI

I recently covered the significance of SwiftUI and how it’s going to change the way we build user interfaces on Apple platforms, which I recommend you skim if you’re unfamiliar. The key takeaway is if you’re able to work within the restrictions of SwiftUI, it will make it easier (and probably cheaper) to create and deliver an app to your customers where they will find the same quality experience on their Macs, iPhones, iPads, and Watches. 

Think about your customer’s wallet

Finally, a new Apple Watch isn’t cheap, so it’s not going to be for everyone. A brand-new small size Series 5 Watch will set you back around $400; an even older Series 3 costs around $200. Now, for a lot of the benefits I’ve covered above, this is less important than the release of the latest operating system, but you will want to consider factors like screen size and whether your app will need the latest hardware. I recommend, before you build the app, carefully considering your own user base and their device usage: Do they already mostly own Watches, and will they really get a lot out of having your app on them?

Want to keep track of the latest Apple Watch developments?

If you’re interested in keeping up to date with what happens with the Watch, and Apple-based app development, I invite you to sign up for my newsletter or check out our latest posts on developing for the Apple Watch. I will let you know when I put out new content and if there are important things you should know when it comes to creating or updating your apps.

The practice is a response to teams of developers making big changes to the code. Often times, teams are working on the code without testing it. As a result, this breaks lots of functionality, making development slow and painful.

This post is a brief introduction to Continuous Integration and how that works when building apps for iOS. I will also cover how you and your team can get started. Additionally, this includes building or maintaining your iOS app cheaper and faster.

Listen to our episode with Kyle Newsome on Continuous Integration to learn more

Continuous Integration Is About Reducing The Cost of Change

Continuous Integration (CI) is designed to help you and your developers. For instance, CI helps avoid that painful moment after everyone has written changes or fixes to your app. As a result, everything needs to b integrated back into the code. In particular, this is known as a merge. Eventually, you discover there are now bugs, errors and conflicts created between the different changes.

As you might imagine, it is messy and unpleasant to untangle the code causing problems and fix them. For developers, this is known as merge hell. For a business that needs the app, it makes any changes very expensive, both in money and time.

CI avoids this problem by requiring developers to write, test, and merge lines of code as rapidly as possible. The original proponents of CI suggested developers merge their code at least once a week. However, daily integration is the most common practice, with some companies, like Netflix, integrating many times a day. The result is that changes happen quickly and if any problems are found, they are small and easy to fix.

There are also a number of additional benefits that CI can bring:

Reduce over-reliance on specific tools, services or individuals

Because CI forces you to make sure everything works constantly on a single source of code, it will quickly expose any ways that prevent you from doing this. This ensures that your app will run on your customers’ machines. As a result. this prevents issues where things will only work with specific tools.

If it can be automated, it will be automated

Core to practicing CI is being able to fully automate all the tests needed to ensure a piece of code will work and automate the deployment process itself. It isn’t possible to merge code on a daily basis without this level of automation. The results should be your developers spending as little time as possible testing and merging their code.

Faster feedback

By integrating code often, you get feedback in the smallest amount of time possible. As a result, this allows you to quickly discover if something works or not.

Helps improve your business

The above doesn’t just apply to writing code; it also allows you to rapidly test how your app works on a business-use level:

• Do your customers like a new feature or not?
• Are they having any difficulties purchasing your products?
• Are they using the app in any unexpected ways?

CI can help you answer these questions quickly and help you create a better experience for them.

Continuous Integration & iOS

Practicing with CI when building iOS apps is the same as with any other platform, but Apple does make things a little more difficult. These are relatively easy to overcome but are worth identifying.

The primary obstacle to practicing CI is Apple’s review process. For instance, if you want to deploy code multiple times a day. With Apple's review process, it ends up being difficult to get your app into the App Store that often. However, if the code change is in a test phase as opposed to production, the review times can be negligible. That is to say, if you use a service like Apple's TestFlight, then the deploy meant can be immediate.

Often, when you have conflicts in an iOS app, they are small but important. For example, you can forget to update a build number (easily forgettable), or not have the right certificates or profiles set up.

Ultimately, Apple simply requires you to deploy apps in a very specific way. Some of it can be automated, but some can’t. This will mean you may need more time than developing apps for other platforms.

How to get started using Continuous Integration

One of the best parts of CI is that it is straightforward to get started with it. You only really need a few things to get started:

Make Sure Your Developers Have All The Same Things

What I mean here is if one developer has a tool or something that is needed to build and test code for your app, ALL the developers should have it. Part of being able to practice CI is being able to reproduce everything your app does on any of your machines. Otherwise, it produces a dependency and will slow everything down.

One Source Of Code Only

In order for CI to work, developers must be working off a single source of code for your app, known as a repository. All code merges are made to this single source. This avoids any confusion and ensures any changes made are only to the most version of your app.

Fully Automate Your Tests

This is absolutely essential for CI. That is to say, an automated testing environment can run thousands of tests in a matter of minutes. (In contrast, it would take hours or days for a human to do manually). As a result of automating your environment, you quickly find out if there are any problems with any change. A point often overlooked but if you don’t have this already, it may take some effort to set up. However, it will easily pay for itself in the time and money it will save you.

There are some excellent services available to help you automate all your testing in the cloud. Some of the most popular ones are BitRise, Travis CI, and Circle CI. Additionally, there’s Fastlane, a software tool for automating the iOS deployment process.

Get A Code Review Process

Along with developing a process for all your testing, there should be a process for ensuring code has been reviewed before it is merged. This ensures that someone is checking for mistakes and also giving feedback to the developers. It is a simple way of catching problems early so you don’t have to deal with them later. Online services like GitHub have mechanisms for this built in, known as a pull request process, which requires someone to approve any changes a developer has submitted.

Know Who’s Responsible

Related to the above, you often won’t want everyone involved to have the same level of authority or access – you shouldn’t have a developer that can make changes without anyone else having to approve them. This is less about the technology involved and more about the people. Who is responsible for what, and if a mistake is made, who finds out and delivers the feedback necessary to fix it? Ideally, you should figure out everyone’s roles and responsibilities before you start.

Listen to our episode with Kyle Newsome on Continuous Integration to learn more

CI Makes Having An App Cheaper, Faster, & Easier

Continuous Integration is a very useful practice for making building, updating and maintaining an app relatively painless. While it won’t solve problems for you, it makes problems visible so you can solve them for yourself. In the end, CI prevents future issues in the long term.

It is normal to experience friction between the people and tools involved in developing your app, but with a little patience, the gains in productivity can be huge. As a result, your team has created an app and a process with faster builds, easier management, and fewer costs.

If you'd like to learn more about setting up CI for Swift and iOS development, check out our article on Swift package continuous integration. Also if you'd like to keep up to date with what’s new for iOS and Apple development, I invite you to sign up for my newsletter. I will let you know when I put out new content and if there are important things you should know when it comes to creating or updating your apps.

Learn more about iOS development, management, and optimizing your process.

Subscribe to the email list to get the latest tips on patterns and practices in iOS and Swift development.

I’ll be covering:

• What makes SwiftUI different.
• When you should use it.
• When you shouldn't.

In this episode, Leo talks about what he's learned using SwiftUI, where he sees it's the right fit, where it's not quite ready, and some solutions to common problems people have with it.

What makes SwiftUI different?

Before now, building a UI for an application for an Apple operating system (OS) has been a bit complicated. You often have to use various tools and frameworks. Most likely Interface Builder (for apps on iOS and MacOS) as well as UIKit (for iOS and tvOS), to build the interface you want. While these are not bad tools, they do have issues and limitations. Apple has clearly developed SwiftUI to overcome or do away these challenges altogether.

No more need for Storyboards or Imperative Programming

Interface Builder is well-known for using storyboards: visual representations of the UI. Unfortunately, storyboards don’t always accurately show what the code is doing. Storyboards do not structure information so it can be mastered or edited in one place. As a result, there is potential for misunderstanding because there’s no Single Source of Truth, a practice developers use to prevent confusion. Typically, the storyboard might not show what’s wrong if it’s not aligned with the code. For this reason, bug fixing becomes especially difficult

Interested in learning more about App Architecture on iOS?
Check out Episode 14 with with René Cacheaux and Josh Berlin

This worked fine in the early years of Interface Builder and UIKit, but the UIs of our apps have now become more complex. This is a problem because UIKit relies on a style of programming called imperative programming. In this style, the code describes exactly how the app must achieve a specific result.

With SwiftUI, we do away with storyboards altogether. Rather than using imperative programming, SwiftUI uses a different style: declarative programming. Declarative programming expresses what the result the software must achieve, but doesn’t describe how this must be done. 

As a result, SwiftUI minimizes unintended results. Additionally, the code is more flexible because it's not limited to a specific procedure.

SwiftUI Works for all Apple Platforms

Tools for building Apple apps have often been limited to some, but not all, Apple platforms. Previously, it has been common to use a different Application Programming Interface (API) for each device. However, with SwiftUI, everything is in Swift and shared across all devices. As a result, it is possible to create an interface with a single API that works on all Apple platforms, from the Mac to the Apple Watch.

SwiftUI has a big advantage over other frameworks because you can build a complete UI with just SwiftUI using only one programming language. This is possible because SwiftUI works in Apple’s latest development environment, XCode 11.

What SwiftUI is good for?

As a result of the above, there are some clearly good uses for SwiftUI:

Apps with simple or cross-platform interfaces

As part Xcode 11, you can use a lot of design tools with SwiftUI, including being able to drag-and-drop visual elements. If you need a simple UI and don’t need custom functions, SwiftUI will probably work perfectly for you.

SwiftUI is really great for the Apple Watch, which is coming into its own now. Since the Watch requires a simple UI, SwiftUI is an excellent choice because it will not only work natively but will work with any other Apple OS too.

New Apps

If you’re going to build an app on for any Apple platform, you might as well start using SwiftUI. You will have all the functionality that Apple is able to provide within a single framework. This also goes for anyone with an app who wants to migrate it to other Apple systems.

For Tech-Savvy Users Using the Latest Apple Products

SwiftUI is a good choice for apps designed for tech-savvy users who are using the latest Apple OS's, like iOS 13. The reason is Apple has developed SwiftUI to take advantage of the latest functionality. This includes things like Apple’s improvements to UI design, UI transitions, animations, and how Dark Mode works.

When is SwiftUI not a good choice?

That all said, SwiftUI is not always the right choice. There are a few instances where you’re either going to need something else, or you’re not going to see the benefits:

Older Apps

If you’re using an app that’s more than a few years old and still supports older Apple OS's, you’re not likely to see any real benefit. There’s nothing your users will really see or appreciate. You’re probably better off sticking with UIKit or whatever framework you’re using.

It’s worth mentioning a downside of using SwiftUI right now: there’s very little documentation. Because it's still so new, we’re still spending a lot of time figuring out how everything works and how to use it. For now, this means there is significant learning time if you want to develop with it. For an older app, you’re not likely to see a great return on investment.

Users using Older Operating Systems or Devices

Related to the above, one of the limitations of SwiftUI is it will only work with the latest Apple operating systems. It has no legacy compatibility. If you have users with older Apple products or who take a long time to update things, they are either going to struggle or simply not be able to use your new UI.

Apps that need to be Android-compatible

Finally, SwiftUI isn't going to help with apps that need to work on non-Apple systems. Swift is only used by Apple and SwiftUI only works in Swift. Therefore, you’ll need a different framework if you want your app to work on Android, Windows, or a website.

I generally recommend not building these kinds of apps anyway, as they rarely deliver the experience that a native app can. I’ve talked about this on my podcast and my blog if you’re interested in learning more.

2020 is going to be an interesting year for Apple apps

SwiftUI is likely going to make building apps for Apple products easier going forward. Especially if you’re comfortable working within the limits of Apple’s new framework. I think the people at Apple were thoughtful with this new framework and it will help create better interfaces for users.

If you're interested in learning more about SwiftUI, check out my Swift developer blog as well as:

• Apple's SwiftUI Tutorials
• Should you write your app in SwiftUI by Nick O'Neill
• You can use SwiftUI today By Gui Rambo
• Using Combine by Joseph Heck
• 100 Days of SwiftUI by Paul Hudson
• Gosh Darn SwiftUI by Sarun Wongpatcharapakorn
• Understanding Combine’s publishers and subscribers By Donny Wals
• Combine and SwiftUI views by Majid Jabrayilov

Test-Driven Development, or TDD, is a way to try to ensure good quality code which will do the job it’s supposed to. This post is for anyone that employs or manages iOS developers and want to deliver better software for their customers.

We’ll be explaining what TDD is, how it works, the advantages are of using TDD, and what you can do to empower your developers to meet customer needs.

What is Test-Driven Development?

Traditionally, requirements for a piece of software are given to the developer. Next the developer then writes what they believe is effective code to meet those requirements. Therefore with TDD, each component of the software is tested to make sure they do what they were designed to do. Specifically, this is known as Unit Testing. In this case, the unit is the smallest testable part of any software. Such as in iOS development, it's typically a method or function which contians a set of instructions.

Here is a simple example of a function in Swift, adding two numbers together:

func add (firstNumber : Int, secondNumber: Int) { return a + b }

In order to test this function, a typical unit test might look like this:

func testAdd () { // test that the result is as expected XCTAssertEqual(add(0,0), 0) XCTAssertEqual(add(1,-1), 0) XCTAssertEqual(add(100,200), 300) XCTAssertEqual(add(-10,-20), -300) }

Test-Driven Development inverts this process by using a test-first approach. So long as the requirements are provided, the developer always first writes the unit tests. Afterwards, the developer then writes the code necessary to succeed at the tests. As a result, the code should always meet the software requirements and generally be simpler and ‘cleaner’. Additionally, the developer only wrote code for what was actually needed. Therefore, you end up with effective software that meets your customers’ needs and has little that they don’t need.

## What makes Test-Driven Development Great for iOS Development

There are a number of benefits to using Test-Driven Development when building an iOS app. By and large, this broadly fits into two categories: Higher-Quality Software and Easier to Maintain.

Higher-Quality Software

One of the realities of software development is that the code for a piece of software will likely change. Typically, as both the developer and the business clarify and improve their understanding of the business problem they are trying to solve, the application needs to update accordingly.

When you have to write unit tests before you write the code, it forces you to decide what features you really. In practice, this means that the requirements need to have a high-degree of detail. As as result, so do the tests can be written based off them. Therefore, it is also almost guaranteed that problems will become clear very early forcing you to solve them.

TDD, by its nature, focuses development on ensuring that the app works the way it was designed to. Additionally it will give the same experience regardless of which iPhone model you might be using.

The result of this is that final app will have far fewer bugs than other testing approaches. Consequently, this means more flexibility and easier maintainability of the code. As a result, this makes it easier to add new functionality later.

Easier to Maintain

So, you have an app that does exactly what it was designed to do, has fewer bugs, and is more flexible. For this reason, it naturally makes your app easier to maintain and update.

What this looks like on a technical level is that TDD forces developers to simplify their code. For one thing, if the code needs to pass a large number of unit tests, the developers would only write enough code to pass each test. As a result, A good developer using TDD will also structure their code in a way that’s easy to modify. In the event a unit fails to pass a test, it’s as easy to go back and fix whatever was causing the failure.

As a result, the developer will have to spend less time rewriting, reorganizing (known as refactoring), and debugging your app’s code.

How you can get started with Test-Driven Development?

How then, can you as a business leader or manager can enable the use Test-Driven Development with your developers?

One of the most important things to start with is management that supports the new practice. TDD is not a panacea, and come with costs. To get the best results, a business should think about having its developers learn TDD as an investment in its future. While it can vary, allowing for a learning period of 2-4 months is a good start.

First, for most developers, TDD is not easy to learn if they’ve used a test-first approach to building software. The biggest challenge will usually be a need to strengthen a developer’s ability to map out the complex array of functionality for an app in the form of specific, planned tests, and their ability to question and review these tests if necessary. This is usually a steep learning curve.

TDD Resources

A good start might be reading the seminal text of TDD: Kent Beck’s Test Driven Development: By Example, the first authoritative text on the subject. Another good book, specifically for iOS and developers using Swift is iOS Test-Driven Development by Tutorials, by Joshua Greene and Michael Katz, which features a lot of examples and tutorials for you to master the basics of TDD. On a more technical level, we cover a lot of TDD-based scenarios and tutorials on Bright Digit’s developer blog.

Additionally, unit testing requires code to be written in order to carry out the testing. In TDD, this test code is just as important as the code of the app itself. Therefore, the code needs to be readable and with the minimum amount of code possible. As a result, this will usually translate into a lot of work, right at the start of a software project. Additionally. your deadlines and budget ideally should be configured to anticipate this reality. However, there will be less maintenance and more flexibility in your code in the long run. And as a result, it will result in more cost savings in the future.

Do you need an app that does what it is designed to do?

At Bright Digit, we have lots of experience using Test-Driven Development and the range of tools and other practices you can use building native apps for iOS. We work with you to make you end up with an app that delights your customers, while being sufficiently tested to make sure you have as few problems as possible. If that sounds like the experience you want to have in developing a successful app, email info@brightdigit.com and tell us about your ideas!

The event told us a lot about the direction of Apple going into 2020, especially for those of us who develop apps for their platforms and want to know what will be the leading edge of innovations for their products. This is also useful for any business or organization that owns an iOS app or is planning to develop one.

Here are the top four things that I think we all have to look forward to with Apple in 2020:

A Slowdown in Innovation for iPhone

2019 may well be the year we have reached peak iPhone. The iPhone 11 series of phones are a clear demonstration of Apple’s expertise and development of mobile phone hardware. However, the 11 doesn’t really have any major hardware innovations compared to the iPhone X, although it is a big step up in performance from the iPhone 8. A clear indication of this was the emphasis on the camera technology above everything else.

This is really good news for those of us who are invested in iOS development. The iPhone has become a sophisticated and mature product. This means that now is a great time to be developing an iOS app. With the maturity of the iPhone where it is, we can rely on it to be a consistent, stable platform for the foreseeable future. Likewise in the future, if you have an app, or are developing an app, it will be relatively easy to maintain your app and there is a low risk of obsolescence if you want to add new features.

Big Breakthroughs Coming for Apple Watch

While the iPhone is maturing, the Apple Watch is just starting to get really good. The new Series 5 introduces noticeable improvements to its power usage, display and storage which show that the watch can be a viable platform. Most importantly, I was happy to see them introduce an always-on display, which makes it a lot easier to use.

At the same time, I don’t think it’s quite become an amazing product yet, but it’s going to be within the decade at the latest. With a little more improvement to its battery and processor, it could become a great hardware platform.

That said, it means now is a great time to start thinking about developing an app for the Apple Watch, especially for organizations in the health and fitness sector. I would venture this could be the perfect platform to have a fitness app in the next year

Potential Change to How We Buy and Use iOS Apps

Although not actually a new announcement, the promotion of Apple Arcade, and its actual launch several days later, is worthy of attention. Apple Arcade uses a subscription model for its video games and is accessible across all Apple platforms. Subscriptions for apps (video games are, after all, a kind of app) is something of a new tack for Apple and shows they are invested in exploring this. I think it’s worth noting how great this could be, especially as it has already attracted some big game developers to get on board: Konami and Capcom. Also: good riddance to micro-transactions!

I hope this will show is the potential for using subscriptions for apps, instead of outright purchases, and Apple expands this into other areas, most especially with their Pro Apps. This hopefully will improve Apple’s app ecosystem, which is lackluster in a few areas – notably with the new iPad. The iPad and especially iPad Pro, though a great piece of hardware, is sadly lacking in Pro apps. Maybe Apple will one day offer the Apple Arcade “bundle” approach for great iOS productivity apps, something the company Setapp is already doing on the Mac.

SwiftUI Changing How We Develop User Interfaces

SwiftUI, Apple’s new user interface (UI) framework, is changing the way we develop UIs for all Apple products by making it easier to quickly develop a dynamic interface that is more flexible and better reflects how people actually use apps. This is happening slowly, as it requires a shift in the way many developers think about UI design, but it has more potential than other, older frameworks, like UIKit. As well, SwiftUI only supports the latest Apple operating systems (iOS 13, Catalina, etc.) and doesn’t support certain kinds of widgets.

Without getting too technical, SwiftUI uses declarative programming, rather than an imperative (which is what UIKit uses). Declarative programming is similar to HTML, as it describes parameters of the UI of a software application, rather than specifying how to draw it on the screen. For example:

Imperative

webpage.drawTitle(“Title”) webpage.drawParagraph(“Lorem Ipsum”)

Declarative

Lorem Ipsum

The other aspect of SwiftUI that makes it promising is that it is cross-platform compatible. This means you can now learn one programming language (Swift) and one framework
(SwiftUI), and you can create UIs for iOS, macOS, watchOS, and tvOS. This is huge for developers, and will hopefully mean we can code for our customers faster, with more consistent, higher-quality results.

It’s still a little early to know for sure what the full impact of SwiftUI will be, but it definitely something to keep an eye on. Time will tell.

Want to Get Ahead of the Curve?

iOS app development is constantly changing and evolving, as you can see from what I’ve outlined above. Knowing what is helpful, unhelpful, or just important to recognize in the field often comes down to experience, being aware of trends, and having a sense of Apple’s goals as a platform and service provider.

At Bright Digit, we are specialists in building apps for iOS. We are attuned to every announcement from Apple and how it could impact our craft. We work with our clients to pass along this knowledge and expertise to them, so they too can keep their apps ahead of the curve, able to deliver the best experience possible to their customers.

If you are ready to deliver that same experience to your customers, email . We would like to hear about your app or plans to make one!

In this post, we’ll cover the major reasons about when and why it’s important to develop an app natively. Additionally, we'll talk about why you should have a specialist to help build or port the app to a new platform. Moreover we'll discuss:

• The Different Methods of Developing An App
• When Cross-Platform Might Be The Right Toolset
• User Experience and Native App Development
• Performance and Native App Development
• Maintainability and Native App Development

A Couple of Points on Terms...

While you’re probably used to seeing many of these terms thrown around a lot, let's define them more clearly.

Native code (i.e. Swift or Objective-C)

In software development, when we refer to native we are talking about using the programming language and toolset that's been designed for the device hardware. As an example, iPhone apps are meant to built using Xcode and coded in either Swift or Objective-C as designated by Apple.

Cross-Platform

Cross-platform development is an alternative method for building apps. Typically, the development team will bring their existing knowledge thereby reducing the friction of developing features for multiple platforms (i.e. Android and iOS). For example, let's say you need develop a shopping cart feature. Rather than writing in Swift for iPhone and then Kotlin or Java for Android, you can use one toolset for the same feature for both platforms. Typically, this is done by writing the code in a single language. The toolset then transforms the code into the native language of the platform. If needed, the toolset will provide additional frameworks so it can run on each supported platform (i.e. Android or iOS).

This post is primarily about why you should write your app’s code natively. Likewise, If you are going to go build for multiple platforms, we'll discuss why investing in having the multiple code bases is important. As well as why it delivers the best experience possible.

Who this article isn’t for

There are many advantages to building an app in the native code of a platform, but before we get to them, we need to be clear we are assuming you are investing the time and effort to produce a high-quality app for your customers or clients with at least technically complex features that you plan to maintain for a long time.

If what you’re looking for is more of a budget-limited app that’s just for recording a grocery list or a minimum viable product for multiple platforms, then you’re unlikely to find this article helpful —the time, effort, and cost to code a native app isn’t going to be anywhere close to the value you’re going to get out of it.

What Makes Native App Development So Great?

There are a number of advantages to building an app in the native code of a platform, that can be broken down into three areas: User Experience, Performance, and Maintainability.

NOTE: At Bright Digit, we specialize in software development for Apple/iOS, so throughout this article, we’ll often provide examples using iOS as an example. However, with perhaps a couple of exceptions, the principles we cover here apply equally in the context of Android or any other device platform.

Native User Experience

If you’re part of a brand or company investing in creating a great app for your customers to use, than you want the best user experience possible. What this means can vary a little depending on whom you’re talking to, but can be usually be boiled down to two key elements:

1. It is easy for the customer to use – the customer can get the desired result they want from using the app in a way that is intuitive and doesn’t require much, if any, complex actions.
2. It is pleasing to use – it is aesthetically attractive, consistent with the app’s brand, and makes some effort to affirm the user’s choices and actions on the app.

When you code your app natively, it should come as no surprise that it is relatively easy to deliver a great user experience: you are working in a format that your device directly understands, so you can make full use of the platform’s features and strengths. You don’t need to go through any additional steps to create a user interface that looks natural and meshes perfectly with the device it is being used on.

Guidelines, Conventions, and Expectations

It also plays into user expectations: using iOS as an example, since most iPhone users know what a great app experience is like on their phone, you can meet that expectation, using the tools provided by Apple to build features using designs that are familiar and comfortable for them to use.

This is an important consideration, especially for those that might be thinking, that by developing a cross-platform app, they want a pixel-perfect identical experience on all devices – this can be a bad idea. iOS and Android users have different expectations about what a great user experience is for their device. Each platform (including macOS, Windows, etc..) has established expectations and UI guidelines about how certain features work and how certain design elements appear. Google has put out their design guide known commonly as Material Design and Apple has human interface guidelines for their platforms as well.

If you use a cross-platform tool to design an identical user interface on both platforms, the result is likely to be the application won’t look quite right on one or all devices. If you try to duplicate a feature from one platform onto one that doesn’t have that functionality, this could present bugs or unexpected behavior in the app, which leads to the next area...

Performance

An issue with cross-platform apps that are written in a non-native language is they require interpreters or some other kind of assistance in translating the code they are written into one the device understands.

Much like the real-life analogy of two people speaking with the aid of a human translator, this slows down communication. When one person says something, the interpreter takes a moment to think about what has been said, and then communicates that message in the native language of the other. Additionally, there may be limitations to what can be said if one language has a word for something that the other language does not (as a human language example, Finnish famously has no word for the English ‘please’ as in ‘please and thank you’). Computers and smartphones have these same limits to their languages, a result of the needs and limitations of their human creators.

When you code an app natively, these kinds of complications and limitations on performance are essentially a non-issue. It should also mean you will have cleaner code for your app that is easier to read and more consistent, both of which are important when considering...

Native App Maintainability

If you’re building an app that you plan to maintain for your customers for years, you ideally want make it relatively easy and cheap to maintain the code. When your app is written in native code, maintenance is simply easier to do, because it usually requires less code and fewer or no dependencies (in software, a dependency is when one piece of software relies on another piece of software to work), resulting in more lightweight app software.

A natively developed app has the advantage of being written in one language that, provided it’s up-to-date, has access to any new features you want to add, as well as a consistent way to find and fix bugs. This is especially important if your app has a lot of complex functions, requires a lot of the platform’s resources, or needs to use a specific Application Programming Interface (API). It also makes it far less likely to have bugs or issues related to the device’s operating system, again because it is written in the same language.

As well, because, using Swift and the APIs provided by Apple (the manufacturer of the device you are developing for) means you are only dependent on that one source over the long term, as opposed to requiring many third-party sources to maintain ever-changing software and hardware, as well as the translator needed so everything can work together.

Ultimately, choosing to develop an app natively not only means it will be faster to get your app into the market sooner because it will generally take less time and have fewer problems, it will also likely make updates to your app simple and straightforward.

Is a native app what your business needs?

Ultimately, while there are reasons where a cross-platform app solution might be adequate for what you need, if you’re committed to deliver a high-quality user experience that can take advantage of a platform’s most powerful functions and is easy to maintain for years to come, a native app is probably your best choice. In the long term, they will deliver better value and be much less of a hassle to own and use.

At BrightDigit, we specialize in building native apps for iOS, usually written in Swift. We work with you to make you end up with an app that delights your customer, while being straightforward to build and maintain. If that sounds like the experience you want to have in developing a successful app, contact us on our contact page to let us know.

That said, with a little knowledge about how an app is created, creating a budget doesn’t need to be daunting. I’ve got some tips to help you with what to consider in developing an app for your business.

I’ll be covering how to figure out both the time and cost of coding, designing and delivering an app to your customers and what kinds of things you should be talking to your developer about before work gets started.

What does your app need to do?

If you approach any good developer with a proposal to have an app built, the first thing they are going to ask is “What do you need the app to do?” An app, at its most basic level, is a set of functions that allow specific actions to be taken: for example, if you run a consultancy, you may want an app with a function that allows customers to book meetings with you. If you have a restaurant that delivers, you probably want a function that allows your customers to search your menu; another for them add items to their bill; another for them to pay.

All these elements are considered by a developer when they are putting together a quote for you, which will include how many functions and screens the app will need and how they will behave in different situations. As well, if you need the app to integrate with third-party services, such as Facebook or a credit payment system, or if the app relies on any special controls or sensors, these will also contribute to a higher quote.

Has somebody already done it?

I’m always surprised how many times people come with a great idea for an app, but haven’t checked the App Store to see if something like it already exists. Not only is this is easy to do, but it’s also a simple way to find out how well, or how difficult, an app idea could be to build and deliver. It can also reveal issues you may not have initially thought of, like how the app handles edge cases or exceptions. This comes up more often than you might imagine, turning something that might have seemed simple into a need for something complex.

As an example, we here at BrightDigit built a nurse training app that covered certification requirements for different States. This, while it might seem simple, turned out to be complex to create, because many users needed ways of tracking their certification training credits in two or more States and credits for each requirement needed to be tracked separately. It certainly wasn’t something the client thought was going to be needed, and while many of the app’s users didn’t need it, it ended up being a necessary feature.

How well do you need it done?

Another factor to consider is the level of quality you need for your app. Assuming you’ve hired a reputable developer, the more time and money you can provide them, the higher quality the app will be: things like a more attractive and easy-to-use user interface, fewer bugs and a way to handle them, or whether you can use the app offline.

Additionally, you need to consider what devices your app can run on. Do you only need it to run on the latest iPhone operating system? What about iPads? Android devices? Desktop computers? Generally speaking, it is worth spending time finding out what kinds of devices your customers use so you only spend resources coding for platforms that are necessary.

How an iOS App can be coded?

Levels of build quality are one of the biggest differentiators between developers. It is possible to get significantly different quotes for the same app depending on how well it’s made. While there are many factors that might have bearing on this, the main one is how the app is coded:

Native

Generally speaking, if you want a better-quality app, you will want it coded in the native programming language of the device you want it to run on. Creating a native app allows the greatest level of control and customization, and are often the best-looking, as they can use all the tools and features of the operating system.

Templates

Some developers might save time and money on app development by using app templates. Effectively, these use premade designs that allow you to add and arrange common app functions. These often have little room for customization or being able to change things later, making them a poor choice if you’re looking for a good long-term investment in an app.

Cross-Platform Tools

Another option that some developers go with is using an application framework, which allows developers to build apps in a script or language other than the one natively used by an operating system. This also has some limits on what you can build into the app.

Web Page Wrappers

Another way is to use a web development wrappers. With this method, you create a web page and have it display as if it were an app. There are some considerable limitations to what you can do with this method though, and shouldn’t be used for anything but the simplest of needs.

How will your app be delivered to your customers?

A smaller consideration than the ones above, but can be surprising for those new to app development, is it can take significant time to get an app into the App Store or Google Play. All sorts of issues might need to be addressed before your app meets the requirements Apple or Google have for putting it in their stores. As well, you should have all your marketing and design assets ready, which are needed to get into the stores. By planning ahead and knowing the requirements of the store before work gets started, you can save yourself significant time and money later on.

Things to Keep in Mind

There are many factors to consider when building an app and creating a realistic project budget:

• Functionality
• Has it already been built?
• Build quality
• Form of delivery

...and that’s only scratching the surface. There are also factors like testing to consider, which we’ll cover in a different post. However, the above is a good starting point for putting together a realistic project budget and having an effective discussion with a prospective developer.

Do you want a well-designed app that delights your customers?

When we work with clients to help them build apps, we want to make sure they can stay within their budget and don’t end up with unnecessary features. Often with new clients, we suggest building a proof of concept of their app idea, so they can quickly put it in front of their customers and discover what features they actually need. Then, when they’re ready, we help them build the full-fledged app.

If that sounds like the experience you want to have in developing a successful app, contact us here and tell us about your ideas!

In the talk, Leo covers the production of a podcast but also the purpose:

Podcasting may sound simple at first but to really be successful at it you need perseverance. Therefore, you need to really have a good reason and passion to do for a while. For this reason, rather than discussing how to start podcast let’s discuss the why. Podcasting - Getting > Started

If you are interested in podcasting, be sure to check out the full article and video from the meetup here.

Therefore, depending on your experience and your budget, here are some guidelines:

Just starting off - under $600 - iPad

You can accomplish a lot with Swift Playground. Rightfully, it’s a great way to start learning Swift specifically. You want be able to deploy onto an iPhone or post to the App Store but it's great way to lightly dabble without commiting.

Under $1300 - MacBook Air, MacBook, Mac Mini

If you want to deploy and test on an actual device or you wish to post to the App Store, you need macOS and Xcode. If you don’t mind losing portability a Mac mini is worth it. Otherwise, what you sacrifice in portability you loose in speed that is building in Xcode will take longer. However now you can actually build, deploy, post an actual app to the App Store.

Under $2200 - MacBook Pro… However

With the recent spate of keyboard issues as well as the rumored transition to ARM, I’d highly recommend waiting on purchasing a brand new MacBook Pro.

Above $2200

Surprisingly, you can upgrade your MacBook Pro all the way to $6600 if you really want to but I wouldn’t recommend it. However, I've purchased an iMac which is what I use and love. Consequently, I would never recommend a developer get a iMac Pro (unless you plan to do game development or multimedia productions) and certainly not a Mac Pro.

Mac for Developers - Other Things to Note

Additionally, buying used is certainly worthwhile. However, make sure that it is recent enough to support the latest as well as upcoming version of macOS.

Finding the right Mac for developers is important, so hopefully you find this helpful in your journey towards becoming an accomplished Swift and iOS developer.

With Swift 5 and ABI stability, Swift has matured into a language ready for new adopters. In this talk, Leo gives an introduction to Swift development as well as its journey. In this session, Leo will cover the basics of the syntax and how it is similar to other languages. This session will explain some differences such as Optionals, Enumerations, and Error Handling. We then build our first iOS Application with navigation, tabs, and a table view. ... If you are interested in getting started with Swift and developing for the Apple Watch, you’ll want to check this workshop out.

Be sure to register for the event at EventBrite. We look forward to seeing you there.

A Plethora Of Choices

Looking at the landscape of back end choices can be rather confusing. In the end, it really depends on team’s skillset. For instance, if you’re using JavaScript to build your web and mobile applications, Node.JS makes sense. On the other hand, if you are .Net developer team, Web API makes sense. Moreover, if you are particularly skilled with PHP, Python, Ruby, Go, etc..., you should stay within your comfort zone.

However for single developers and developer teams (such as me) which focus on Apple products, there isn’t a dedicated framework for server-side applications. Therefore, the closest option is CloudKit, which is good for data storage but lacks options such as:

• No support outside of web and Apple devices
• No support for complete backups
• Locked into the CloudKit data model for relationships
• No Cron Jobs

However there are other options to remain developing in Swift on server.

Vapor - Swift for the Server

Since Swift was open sourced in late 2015, compatibility for other operating system has been added. One of the first teams to move Swift to the server was the Vapor team. Since the release of version 3.0 in May 2018, interest has grown.

In this article, I will review Vapor and cover:

• Ease of Installation and Deployment
• Developing For Vapor
• Database Support
• Event-Driven Async API

Therefore, let’s begin by talking about how easy it is to get started.

Getting Started with Vapor

In this article I recently published, I showed how to get started by installing Vapor on your Mac and Ubuntu as well as services like Heroku. In short, I found the process to be pretty simple and effective. That is to say, it is no more complex then any other web framework.

For instance, on the Mac, developers can use Homebrew, which is fairly common, to tap the Vapor repo and install. After you have access to the Vapor CLI tool which includes a subcommand for setting up your Heroku application with the Vapor buildpack.

Likewise on Ubuntu, you add the apt repo for Vapor and install via the apt command. Having done that, you can easily use a combination of a process monitor and an http server to proxy the server.

If you are interested in more details on this process, check out this article which deep dives into Vapor and setting up for macOS, Heroku, and Ubuntu.

Developing with Vapor

Having installed Vapor, the next part of the procedure is developing the app. As a result, the IDE is very important.

Developer Tools with Vapor

In spite of its issues, we can still develop in Swift with Xcode. However, since there are command line tools to build a Swift application and a developer could choose their own tool. At the present time, the real limitation is that Swift in general is only supported on macOS and Ubuntu. That is to say there is no support for other Linux or Unix operating systems as well as no support for Windows. However, the community is certainly moving forward with extending support in those areas. Similarly, the community has provided plenty of packages.

Third Party Support for Vapor

Node.js has npm, Ruby has gems, C# has Nuget, Python has pip and Swift has the Swift Package Manager. Generally speaking, the Swift Package Manager or SPM has been slowly adapted as the premier dependency manager. In the long run while Cocoapods and Carthage still reign in the area of iOS development, it is inevitable that SPM will dominate in the future. Having discussed outside support for Vapor, let’s discuss what Vapor (and its package support currently).

Database Support and Fluent ORM

My experience working with various ORMs are varied. Being that I’ve worked with Entity Framework in C# and Sequelize for Node.Js, I have some experience. Having said that, what makes these work so well is the ability to use lambdas and implement many functional programming paradigms. As a result, since Swift has that ability, using the Fluent ORM is fairly easy to learn.

Equally important is its support of various database software. As of now, there is support for:

• MySQL
• MariaDB
• MongoDB
• PostgreSQL
• SQLite

As can be seen, there is sufficient database support. Not to mention, but its support for those databases is fairly deep.

Deep Database Support

For instance, I ran into an issue where I was searching for objects by title - a fairly simple keyword search for a REST API list operation. However, what I didn’t realize was that many titles have diacritcs, specifically accents. In other words if a user searches for something with an e if a title has an é, that result won’t show up. In spite of this, there is code in PostgreSQL to unaccent a string, such as there is a way to do lower or upper case transformation. Having adding the necessary functions, I am able to call the function with Fluent’s API:

let columnId = PostgreSQLColumnIdentifier.column("Game", "title") let column = PostgreSQLExpression.column(columnId) let arg = GenericSQLFunctionArgument

.expression(column) let args : [GenericSQLFunctionArgument] = [arg] let expression = PostgreSQLExpression.function("unaccent", args) As shown above, this may not be ideal, but it works. In addition, you always have access to lower level, direct SQL code using the Database Kit API. However what truly makes Fluent ORM so robust is the use of SwiftNIO async API.

### The *Future* of Programming In short, [SwiftNIO](https://github.com/apple/swift-nio), the event-driven network application framework started by Apple, provides a set of types for handling callback-based asynchronous APIs such as database queries. In addition, Vapor provides a set of functionality which make complex queries accessible in code. That is to say **SwiftNIO and Vapor provides futures and promises as well as and API for dealing with multiple objects such as transformations**. Despite this, **the most significant friction I have found was the combination of Xcode and Swift compiler delivering misleading error message.** At present, this is very common complaint with Swift and Xcode in general but it is certainly an issue worth mentioning. Likewise, I used the same async API when making various HTTP calls and found it very reliable. ### The REST of the API As opposed to URLRequest, **the HTTP API is promise/future friendly** which is nice improvement. However, any async call in Swift can easily be made friendly. In addition to the Fluent ORM, HTTP, and Async APIs, I did make use of the Auth, Crypto, and Routing APIs. In short, all worked flawlessly. For instance, serialization from JSON or Multipart encoded data works without much needed implementation. That is to say, if you are implementing a type which correctly implements Codable then there should not be much extra effort in creating a robust REST API. However, if you do need to customize your type to use Codable, I highly recommend my post on improving how you decode JSON.

## Vaporware or Swift-ly Switch? To sum up, **Vapor is already a healthy framework to start any new server-side application**. However, I would never recommend anyone rewrite their whole application in this. Overall, **if you are already Swift team and you are looking to move some if not all your code to a new framework, I’d highly recommend taking a look Vapor as your first choice.** Not to mention, if you are using a web framework that is becoming a burden and **enjoy the versatility of Swift, going with Vapor would be good fit**. (Besides that, the only caveat I’d make is that if you are building for the enterprise I would look into [Kitura](https://www.kitura.io), the IBM team has plenty of experience in that space and [Kitura](https://www.kitura.io) seems more focused in those regards.) On the other hand, if you are using a web framework which has performed well for your team and most of your development is not in Swift, then switching to Vapor does not make sense. Lastly, I just wanted to point out, that Vapor works well outside of an Apple client application. For example, **[I successfully built a web application using VueJs and Axios](https://redmushroom.club?utm_medium=web&utm_source=learning-swift) and had no difficulty when it came to server-client communication.** If you are interested in getting started, [subscribe to this newsletter](http://eepurl.com/gk8mp5), to get started guide as well as updates on how to develop a robust application with Vapor.]]>

Leo Dion of BrightDigit will discuss what should be done to get started as well as how what skills you can nurture to become a successful freelancer. We'll talk about what is needed to manage your money, your reputation, and your time. If you are thinking about freelancing or just curious about what freelancing involves you’ll want to check this out.

I have posted the slides as well as the video of the event which you can check out.

What questions do you have? What challenges have you faced along the way? Let me know on Twitter what are your thoughts.

Health Features

While the new Apple watch announcement touted all sorts of functionality, health features took a starring role.

Basic Electrocardiogram

First, this watch can now take a basic electrocardiogram (ECG). While this in no way replaces a full ECG workup in a hospital or doctor's office, it should be a useful indicator that something could be up with your heart and worth discussing with your doctor.

Apple immediately tempered any skepticism of the watch's ability to perform a medical function by announcing…

FDA and AHA Support

Both the Food and Drug Administration and the American Heart Association gave the new watch a qualified endorsement. While it could take 5-10 years for a watch to be officially considered a medical device, both organizations consider the health features that Apple is putting into the watch a good thing.

Siri! I've Fallen!

The new Apple watch added another health feature that alerts both wearer and potentially emergency services when the wearer falls. If the accelerometer in the watch registers a fall, it notifies the wearer. If the wearer does not respond to the notification, Siri will call out to emergency services.

It is not yet clear how the watch handles edge cases. For example, if someone gets drunk and passes out, will Siri phone 911? Still, this technology could increase the independence of seniors and other users with mobility issues.

Hardware Changes

While health functionality headlined the show, the Apple watch 4's new hardware was nothing to sneeze at. An upgraded processor makes the watch twice as fast as its predecessors (in terms of processing speed). Even more striking is the increased screen size on the watch face.

Thankfully the new screen sizes will work with the previous generation of watch bands. For example, the new 40mm screen will work with the older 38mm watch bands. But with the increased screen size and reduced bezel, that same new 40mm screen will have more usable screen space than the old 42mm screen did.

When Should I Make A Watch App?

With the renewed emphasis on health apps and the increased screen space, does it make sense for your business to make a watch app?

First, anyone in health or fitness should consider adding a watch app to their offering. Apple has both grown the market for smartwatches and demonstrated that users are interested in health and fitness tracking.

Second, the new Apple watch is still a fantastic platform for any feature that tracks time or time-based activities.

Third, though the iPhone isn't going anywhere, as a platform it's stabilized. The Apple watch still has plenty of room for growth, and that means more business opportunities.

Fourth, if you have already an iPhone app, it likely makes sense to add watch notifications if you haven't already. The watch is not a device that you can purchase and run solo; it needs an iPhone to unlock its full capabilities.

Where Can I Hear More About the New Apple Watch?

For a wide-ranging discussion, check out the Empower Apps podcast episode on the Apple Watch Series 4.

If you need help bringing a watch app to market, get in touch with BrightDigit. We'll point you in the right direction.

How did you get into machine learning?

I’ve had my eye on the field for many years. However, the large learning curve and hardware requirements had put me off. Recent amazing advances in the field, particularly with reinforcement learning and creative computation, made me decide I had to get involved.

I come from a design background, and I’m particularly interested in how AI and machine learning can help augment human creativity and intelligence. There’s a huge opportunity for folks not coming from Computer Science backgrounds - people who are designers, artists, and humanists - to get involved and help build the next generation of AI tools.

## What are you most excited about in regards to the future of machine learning?

We are still in the very early days of this technology coming into wide usage.

Andrew Ng often refers to AI as “the new electricity” and I think it’s an apt metaphor. I believe Machine Learning will be ubiquitous in every aspect of our digital lives.

Machine Learning has traditionally required huge investments in both computation and data, giving large technology companies insurmountable advantages. In the past few years, that’s begun to change.

On the hardware side, a number of startups (and more recently, Google) have begun offering more and more powerful GPUs for cheap or free. On the data side, we’ve seen progress with techniques like synthetic data generation, few-shot learning, and transfer learning, allowing programmers to achieve extremely accurate results with very little data.

There is a ton of opportunity to shape and contribute to the field, and we’re at a unique time where you can have an outsized impact.

> I think there’s a huge opportunity for folks not coming from CS > backgrounds - people who are designers, artists, and humanists - to > get involved and help build the next generation of AI tools.

Do you have a simple explanation of machine learning for people who are unfamiliar with it?

Machine Learning is the technique of teaching computers to recognize patterns in data.

It has its roots in the field of statistics and math, and in fact statistical methods continue to be used for many problems in the field of machine learning.

Deep Learning is a subset of machine learning, and refers to neural networks that have many hidden layers (aka, “deep” networks). Deep learning models, when given access to lots of data, can become extremely accurate. They also have the ability, to some extent, to “figure out” the patterns in the data themselves (as opposed to more traditional machine learning techniques like feature engineering).

**There is a ton of opportunity to shape and contribute to the [Machine Learning], and we’re at a unique time where you can have an outsized impact.**

How do you see big technology companies taking advantage of machine learning?

Every technology company is investing massive resources in machine learning. They all accurately recognize it as the next major sea change, and recognize that investment in AI technology will result in better products in both enterprise and consumer software.

Apple has been baking machine learning capable tools into XCode and Swift for years now. CoreML and create-ml are two examples of this.

Google has probably the most recognizable efforts in AI today. You can see AI at work in Gmail’s auto suggestions; in Google Photos’ assistant, automatically suggesting styling options and tagging; in Google Translate; and in Google Home, answering your queries.

## What specific area do you think is the most exciting?

I’m most excited about transfer learning and one shot encoding. Both techniques allow regular folks to get great results without access to powerful hardware or large data sets.

Technology-wise, I’m most excited about the idea of GANs. GAN stands for Generative Adversarial Network, and the idea is to take two neural networks and pit them against each other. For instance, one application has a neural network attempting to generate realistic celebrity faces, while another attempts to pinpoint the fakes. The final result is indistinguishable from real photos. These kinds of tools will enable great new bounds in human creativity and innovation.

What is the best way someone can get started in learning more about bots and machine learning?

Fast.ai and Andrew Ng’s Coursera course are probably the most popular beginner intros to deep learning. They’re both wonderful introductions to the field.

From there, it’s largely up to your specific interests. Images and vision, natural text, reinforcement learning, and others are all differing specialties that require their own sets of skills. Kaggle is a great data science website that posts challenges you can compete in as well.

My recommendation would be to figure out what excites you about the field and focus on a single area. I’m particularly interested in applied machine learning, and so my focus has been on inference in the browser, leveraging transfer learning.

## How can the average businessperson leverage the power of machine learning?

If you’re sitting on a large amount of data there are likely opportunities for machine learning. A good rule of thumb is to look for things having to do with prediction. Anywhere there’s patterns, it’s likely that a machine learning model could generate predictions automatically.

If you are interested in learning more about Machine Learning, I highly recommend subscribing to Kevin's blog to learn more.

At this event, Apple typically announces and unveils the latest iPhone and other devices. And beforehand, everyone loves to guess what will happen. What are the best guesses and leaks?

Everyone is convinced that we will see three new iPhones: an improved X, a plus-sized X, and a "budget" version of the X. We also hear rumors of a new Apple Watch.

6.1 inch iPhone 9

Rumor has it Apple will be releasing a new 6.1 inch iPhone with an LCD display and only one camera lens. The LCD display and one camera lens will likely reduce the cost of this phone and make it more competitive with other smart phones in the market. The rumored price on the device for the Apple September event is around $600 - $700 USD.

iPhone Xs Plus

The iPhone Xs plus will have the usual number of camera lenses, as well as the OLED screen. The dual lens camera offers greater zoom levels and a portrait mode. While the OLED screen reduces battery usage while giving a more natural blacks on the screen.

However, the biggest difference will be the size: 6.5 inches. This means it will be nearly the same size as previous plus sized phones but with a large screen. The iPhone Xs Plus will have the same top notch and all screen front display. There will be updates to the processor, likely from the A11 Bionic, and there may be updates to the material and color options.

This will probably be the release cycle in which no new iPhones have a Home button. Meanwhile, the Face ID technology could be improved on the new model this year. Plus-sized iPhones are not the only ones getting an update at the Apple September event as far as more screen and less bezel but the Apple Watch as well.

Apple Watch Series 4

The new Series 4 Apple watch is rumored to have the most striking changes. The bezel size will also be dramatically reduced, making the display larger by going edge-to-edge. Having a larger display should allow the user to see more information and widgets at all times.

In a welcome move for consumers, the bands from the previous version will still fit this latest model, and the Apple Watch will remain waterproof.

The Apple Watch has seen steady improvements in processor, battery, and communication. This new model will the larger display is certainly the biggest improvement yet.

## A New iPad?

Also rumored: a new iPad Pro that will continue the trend of less bezel and a larger display. This could also mean that Face ID will be moving to the iPad as well. If this happens, this should greatly improve the login user experience. On the iPad, especially, it can be extremely cumbersome to put your thumb on the device if it is at a distance. And instead of using the home button, the user will use gestures (swiping) to navigate the device.

New Laptops Too?

There are also rumors of a new "budget" MacBook (i.e. MacBook Air) and a new Mac mini. We'll have to wait and see just how the upgrades stack up.

Want to find out more about the upcoming Apple September event?

Be sure to check out the latest episode of the EmpowerApps.Show podcast where Leo and Theresa dig deeper into the upcoming Apple releases.

Phasing Out 32 Bit Support for Applications

Apple has announced that Mojave will be the final OS to support 32-bit. With this change in Mojave for developers, you have one year to get ready and update your build for 10.15, the first 64-bit only OS from Apple. Otherwise your ancient 32-bit app will no longer work in the fall of 2019.

Enhanced App Permissions in Mojave for Developers

macOS Mojave now requires your apps to request permission when using the camera, microphone, or any automation (i.e. AppleScript and Apple Events). This means if your app uses any of those functionalities, you'll need to update your code to ask for those permissions as well as handle when permission is not granted.

Dark Mode and Mojave

Safari Privacy Features in Mojave

UIKit Coming to the Mac

[caption id="attachment_1285" align="aligncenter" width="896"] example of "Marzipan" in action on Mojave with the Stocks app[/caption] UIKit is the framework for developing the user interface of iPhone and iPad apps. There have been rumors of “Marzipan” a bridge which brings UIKit over to the Mac. In this post on macOS development for iOS developers, we speculated about what ”Marzipan” could be. Well this year they announced that they will be bringing it to Mac developers... probably next year. They have also given us a preview in Mojave with apps like Home, Stocks, News and Calculator. While we can see the resulting apps, there are still plenty of questions like:

• How will these apps look?
• How easy will the framework be to use?
• Will it be easy to build a Mac App and an iOS App at the same time?

• Making sure you are organizing your code to use newer APIs and methodoligies
• Avoid deprecated code and APIs
• Use other frameworks and APIs properly which are available across Apple's platforms such as CoreData, Metal, CoreML, and more...

Conclusion

With all the new features in Mojave for developers, Apple has given us a roadmap for the first time. This means we have time till 4Q 2019 to:

• Update macOS apps to use 64-bit only
• Support Dark Mode in your UI
• Support Enhanced App Permissions (camera, microphone, etc...)
• Clean up your architecture to use cross platform frameworks and APIs properly.

If you have a spare Mac or a spare partition on your hard drive, go ahead download and try macOS Mojave through the developer program or the beta program today. Do all these changes in Mojave have you wondering just how you're going to keep your app current? If you need help updating your macOS app, contact Bright Digit today.

This wasn't the "flashiest" year for WWDC but some important changes were mentioned that affect businesses. It appears that Apple is addressing concerns from the past year and doing some behind the scenes house cleaning. These behind the scenes improvements might not grab the headlines but they make a big difference for users and businesses.

An iOS Update For Everyone

Both inside and outside the Apple world, lately there has been a fair share of bad press and scandals. These reports are especially regarding security issues, battery life, speed and bugs. As a result, this year they have delivered the first update in awhile in which devices supporting the previous OS support the update. That means all devices which support iOS 11 can update to iOS 12:

iPhone

• iPhone X
• iPhone 8
• iPhone 8 Plus
• iPhone 7
• iPhone 7 Plus
• iPhone 6s
• iPhone 6s Plus
• iPhone 6
• iPhone 6 Plus
• iPhone SE
• iPhone 5s

iPad

• 12.9-inch iPad Pro 2nd generation
• 12.9-inch iPad Pro 1st generation
• 10.5-inch iPad Pro
• 9.7-inch iPad Pro
• iPad 6th generation
• iPad 5th generation
• iPad Air 2
• iPad Air
• iPad mini 4
• iPad mini 3
• iPad mini 2

iPod

• iPod touch 6th generation

Additionally one piece of news that should make everyone happy is that older devices actually run faster with this update. This means if your company has older iPads, such as the iPad Air, or older iPhones like the iPhone 5s or iPhone 6, it will probably be worth your time to update your devices. For developers, expect very high adoption rates of iOS 12 and little reason to support iOS 11 for much longer.

Mac App Store Improvements

The Mac App Store has received its fair share of criticism. Compared with its iOS counterpart, it has seemed neglected and insufficient for the macOS software market. Apple has decided this year to make a bigger push towards getting software developers onto the Mac App Store.

Better Models For Businesses

Not only are they migrating the magazine format from the iOS App Store over to the Mac but there are changes to the restrictions on apps and their business model.

Recently, Apple has included a better subscription model. And now they are including something like a "Free Trial" offering available from the Mac App Store. There will also be improvements to how sandboxing works. Sandboxing is a way to isolate the app and the files it uses from the rest of the data on your computer. This improvement to sandboxing has allowed Mac developers at Panic to publish their app Transmit to the App Store. As far as their pricing model, Panic will be doing a subscription model on the App Store and allowing a one-time purchase on their website.

> The Mac App Store is already home to some of the best apps in the > world. But there's plenty of room for more 😉
>
> Here are just a few of the awesome developers coming to the all-new > Mac App Store. > #WWDC18 > pic.twitter.com/UmWZVVDV8U > > — App Store (@AppStore) June 4, > 2018

There are also other big software companies moving to the App Store, such as Microsoft and Adobe.

If you're interested in learning more about macOS development, check out our article on macOS development for iOS developers. Now is a good time to at least consider publishing your app to the mac.

Using Social to Showcase AR

Since the release of the iPhone X and AR Kit, Apple has continued to showcase it's AR features with Animoji and now Memoji. Animoji would use a set of cute animated characters which mimic your facial expressions using iPhone X technology. With iOS 12, Memoji allows a user to create an animated version of themselves. It's easy to view this as a bit of a gimmick. However, we must keep in mind what is going on "under the hood." Memoji is a way to demo the exciting new AR and machine learning technology behind it.

Businesses should continue to watch trends in ARKit and CoreML and consider how these tools may help their business.

Encouraging Productivity

Just as Google introduced new ways to control phone usage on Android, Apple is doing the same on iOS 12 with Screen Time. Screen Time allows users (and parents) to limit app and overall phone usage.

Users can always avoid following through on these limitations by overriding them with a pass code. However, it's important for businesses to keep in mind that users can place these limits on their apps.

Plenty For Businesses to Prepare

In iOS 12, Apple has introduced Screen Time which encourages associating the iPhone with productivity and less with addictive games and social networking. Apple is also showing their commitment to older devices by making them faster and more reliable in iOS 12. There is a strong indication that Apple sees a big future in the Augmented Realty and Machine Learning space as they introduce more features in ARKit, CoreML, and Memojis.

On macOS, Apple is encouraging more developers to move to the Mac app store. There are more improvements coming to the new version of macOS, Mojave as well. We will talk about these in our next post.

In today’s episode, the iPhreaks panel talk to Leo Dion about MicroConf and writing apps for Apple Watch. Leo has been a developer for almost two decades and six years ago he created his own company called class="s2">BrightDigit. He mostly focuses his time and energy to the Apple space and enjoys developing apps for the iPhone, iPad, and the Apple Watch. They talk about what happens at class="s2">MicroConf, what he is working on now, tips for starting a meetup, and more!

You can check out the episode here.

It is incredibly difficult for a business in this day and age to succeed without having a good website. Customers expect to be able to find you online, see your hours and find ways to contact you. When your customers lack information; they are confused, frustrated and are inclined to look elsewhere.

Why have a website?

Having an updated, easy to navigate website makes a huge difference. It doesn't need to be fancy but it does need to easily present the basic information about your business. It can be tempting to make the website yourself or perhaps ask a family member to create it for you. However, you will save yourself a lot of trouble in the long run if you hire a professional from the beginning. It is similar to building a house. If the foundation isn't done correctly, everything else will slowly fall apart and have problems. Having a bad website will frustrate your customers and will be worse than not having a site at all! [bctt tweet="Customers expect to be able to find you online, see your hours and find ways to contact you. When your customers lack information; they are confused, frustrated and are inclined to look elsewhere." username="brightdigit"]

What can you do next?

There are three things you can do to better understand your website:

Do What The Best Sites Do

Look at the sites of other businesses similar to yours and copy what they do best. Make sure not to be overwhelmed and look at the most important pieces.

Be The Customer

Pretend to be a customer of your business. What do you like? What do you not like? Is anything frustrating? Is anything easy? Once you start to get a sense of these things, I am sure you will begin to recognize how your site can be improved.

Talk To Your Market

Ask yourself, how would a customer would try to find your business? If they found your site, would they easily find what they need? Or is there room for improvement? Once you've asked these questions and have done some research, the next step is finding someone to do it. [bctt tweet="If the foundation isn't done correctly, everything else will slowly fall apart and have problems. Having a bad website will frustrate your customers and will be worse than not having a site at all!" username="brightdigit"]

Finding the Right Web Designer

The easiest way to find the right designer is ask for recommendations. Here are few people who could help:

• If you see a site you like, find out who built it.
• Ask other business owners for recommendations. Most business owners will be more than willing to help.
• Talk to family and friends. They may use a great service or know someone who does.

Once you have a good set of references (and their references as well), think about your expectations and start inquiring about quotes. And remember keep your site simple for the first version or a redesign because you can always add more content later.

Getting a Web Site the Right Way

• You can build your own website but **you may not have the time to upkeep it yourself.**
• Asking a friend or relative to do it for cheap could result in website that is **unable to be maintained or could be a poor foundation for the future**.
• When looking for the right web designer, be sure to **ask around among business owner especially those with high quality web sites.**
• Finally, keep the first version of your site simple. Then build content on top of it in the future.

Good luck with this new and exciting endeavor! If you have any questions, you can always contact us. SaveSave

Why Should You Get Into Mac Development

There are some very good reasons to get into Mac development if you already are an iOS developer.

Market Potential

Many app developers will tell you how difficult it is to get users to find your app, use the app, and then give you money through some means. macOS has a greater expectation that software is less frivolous and therefore can be more expensive. There is some truth to this since if you're already willing to put cash down on an iMac, iMac Pro, or Mac Pro spending money on software would barely be an expense. With that though comes that your software is more than just another social network app or streaming app but a professional application for creating or building something.

Companion App

By building a macOS companion app for already existing iOS app, you can reach a whole other market and perhaps earn some credit from the folks at Apple. By having your app in macOS as well you offer more versatility for more complex operations and a more open operating system.

How To Get Into Mac Development

Similarities

By already being an iOS developer, you already bring a lot to the table when it comes to Mac development. For one thing you don’t need to learn a whole new programming language. Whether you develop in Objective-C or Swift, you can bring that with you to Mac development. There are also many frameworks which have common or similar APIs such as Core Data, Core Graphics, CoreML, and more. For more details check out Apple’s guide on migration.

Differences

With API that is at least 10 years older, there’s liable to be many differences when it comes to iOS and macOS development. iOS is based around Cocoa Touch with UIKit as the primary UI framework. macOS on the other hand is based around Cocoa and uses AppKit for its UI framework. The main differences come down to methodologies, language support, UX, and hardware.

Methodologies

AppKit, the primary UI framework, was originally developed at a time before many modern programming concepts had arrived. So while UIKit uses a Target-Action model, as well, delegates, and closures; AppKit uses mostly Target-Action for method signatures. Another thing is the use of Cocoa Binding for mapping data to controls using key paths. Cocoa Binding is more based around the Model-View-ViewModel pattern as opposed to Model-View-Controller pattern when it comes to displaying model data. While Cocoa Touch has evolved along with Swift much more fluidly, Cocoa, is still restricted by backwards support and being an older framework.

Language Support

With Objective-C being the more primary language with AppKit, there is a heavier use of the target-action model, selectors, and accessor methods. Selectors while available in Swift tends to be more awkward in use. Typically UIKit will have selectors but usually have an alternative way as well to respond to events such as delegates and closures. Accessor Methods are used throughout Cocoa and AppKit rather than Properties which are used throughout Cocoa Touch and UIKit. Also the prefixes for many classes use the NextStep prefix “NS-“ still rather than the UIKit prefix “UI-“.

Development Workflow

There are some things which make developing macOS on macOS hardware. For one thing, there is no need for simulators. However this means you no longer have access to every model which the operating system could be on. This should rarely be an issue but there are times when certain Mac models have differing capabilities and differing speeds. One difference with Macs are the differing screen sizes. Over the years iOS screen sizes have grown in variety quite a bit but macs have a practically infinite possibilities with screen sizes. Of course macOS apps unlike iOS apps don’t always run in full-screen.

Human Computer Interaction

With macOS apps running in multiple windows comes a different classic way to interact. With iOS, apps typically have one UIWindow which take up the whole screen however macOS apps have multiple NSWindows which can a wide variety sizes. UIWindow is a subclass of UIView; NSWindow is not a subclass of NSView. Also there are a variety of devices you may need to interact with including the mouse and keyboard. NSEvent along with varying delegate, controller, view, window methods, are the ways you can respond to various mouse and keyboard events. Menus can also be more complex and come in a variety of types such as context menus, pop-up lists, status bar menus, and more. There is also a variety of classes which may sound similar but aren’t. One example is NSTableView and UITableView. While UITableView is used for menus, lists, and other purposes in iOS, NSTableView is pretty much a strict table with rows and columns and is used for those purposes. The other major difference is the way documents and the file system is handled. macOS comes with more complex document handling and depending on how your app is setup with sandboxing the user may have differing access to the actual file system.

Remedies For Porting to macOS

There are few method to porting code over from iOS to macOS. All these methods are valid and could be used together in various ways:

• Just Copy the Code
  • more code to maintain
  • most flexible
  • least consistent
• Use Lower-Level Common Framework
  • less code to maintain
  • more difficult to provide functionality
  • some consistency
• Use Adapter Pattern
  • less code to maintain than copying
  • more consistency with some flexibility
• Preprocessor Directives
  • use for small pieces of code which have little difference (i.e. NSColor / UIColor, etc…)

What’s the Future of macOS Development?

With talk about the Marzipan project, which is supposed to unify iOS and macOS development, the question becomes “What is the future of macOS development?”.

Porting iOS UI to macOS

Apple could port classes such as UIViewController to macOS and only make minor modification for macOS. This could mean a jaunty experience on the Mac but the easiest experience for developers.

UXKit

UXKit, a private framework, used in the development of the Mac Photos app could be made available to the public. The Photos app while visually appealing has received many criticism for its awkward experience on the Mac.

Unified Abstract Layer

A new framework which abstracts UIKit and AppKit but also offers way to hook into AppKit and UIKit if needed such as the way UIKit or AppKit allow access to Core Graphics. This would offer the most flexibility while removing all of the repetitive code.

Similar to watchOS and tvOS

Apple may also follow their pattern with watchOS and especially tvOS which have many similar UI type features but also have many differences.

Conclusion

If you are thinking about getting into macOS development, I think now is the best time to do it; especially if you are already an iOS development. It is not something which will be easy however being fluent in Swift or Objective-C and having knowledge of some of the common frameworks used will help. With hopefully whatever the Marzipan project brings will smooth out of the rough and outdated piece of the macOS api but coming with some of that legacy knowledge will help.

AppleScript is a great technology on macOS for both developers and power users. It allows users to create automated processes which work other apps. As a developer though, sometimes you want a build an app in Xcode with the power of AppleScriptwithout the need to have separate script files. To work with AppleScript in any app, there are two options to do this:

1. Write a separate AppleScript file and use the NSAppleScript API to execute and run the script.
2. Use ScriptingBridge to work with AppleScript in Swift or Objective-C.

We are going to look at the second option: ScriptBridging. In particular, how to use ScriptBridge in Swift wihout the need for AppleScript files or event Objective-C bridging.

The Drawbacks of ScriptBridging

It should be noted if you intend to write an App for the Mac App Store there are restrictions as noted by Apple. You can also look at this article by Craig Hockenberry which shows how you can use the AppleScript API in a Mac Store app. The bottom line is: You can not use ScriptingBridge with an app in the Mac App Store.

Objective-C ScriptBridging to Swift ScriptBridging

When it comes to Objective-C ScriptBridging, Apple already provides tools to prepare the code. Luckily, Tony Ingraldi of Majesty Software, has a great set of python scripts for creating the same code in Swift. For more details on this specifically take a look his repo on GitHub or his blog post here.

ScriptBridging with Safari

Now let's try doing this by writing an app which pulls the tab urls out of a Safari window. The repo for this app can be found here.

Building the Swift Code from AppleScript Definition

Download the python scripting tools from the SwiftScripting repo on GitHub. From the repo's directory, run the following commands:

pip install clang sdef /Applications/Safari.app > Safari.sdef sdp -fh --basename Safari Safari.sdef ./sbhc.py Safari.h ./sbsc.py Safari.sdef

Let's break this down:

1. pip install clang - ensures clang is installed for python
2. sdef /Applications/Safari.app > Safari.sdef - gets the scripting definition from the specified script- able application
3. sdp -fh --basename Safari Safari.sdef - transforms a scripting definition to an Objective-C header file
4. ./sbhc.py Safari.h - transforms the Objective-C header file to Swift
5. ./sbsc.py Safari.sdef - extracts the enums from the standard definition to Swift

Now you should have 4 new files:

• Safari.sdef - the scripting definition file, which is used to build the code
• Safari.h - the objective-c header file, which we would use if we were doing objective-c directly or using objective-c bridging
• Safari.swift - the primary file containing the main ScriptingBridge API to the application
• SafariScripting.swift - the nessecary enums needed by the ScriptingBridge API for the application

Since we are using only Swift code, we will only need the two Swift files (Safari.swift and SafariScripting.swift) in our application. Add the two files to your project in Xcode and now in our application we can talk to Safari.

Using the ScriptBridging API for Safari

To pull the all Safari windows currently open:

if let application = SBApplication(bundleIdentifier: "com.apple.Safari") { let safariApplication = application as SafariApplication let safariWindows = safariApplication.windows?().flatMap({ $0 as? SafariWindow }) ... }

We call the SBApplication constructor using the bundle identifier. If an object is returned, we cast as the SafariApplication protocol and get all the windows. The

windows property only returns a SBElementArray, so we need to cast those elements to a SafariWindow. From there we can get the window's set of tabs:

let safariWindow = safariWindows?.first let safariTab = safariWindow?.tabs?().firstObject as? SafariTab let url = safariTab?.URL

Let's break this down:

1. let safariWindow = safariWindows?.first - get the first Safari window
2. let safariTab = safariWindow?.tabs?().firstObject as? SafariTab - get the first tab of the Safari window and cast it to SafariTab
3. let url = safariTab?.URL - get the url of that particular tab

If you need more details checkout the repo for the sample app called jURLnal which copies the URLs to the clipboard.

Conclusion

So as you can see -

1. We have used the standard ScriptBridging tools to build the standard definition and Objective-C header file of Safari’s AppleScript API.
2. We used a set of python scripts from Tony Ingraldi of Majesty Software to convert the Objective-C header file and standard definition to Swift code.
3. Added the two Swift files to our project and used the API to extract the windows and tabs of the currently open Safari application.

If you have any questions, comments, or thoughts, be sure to post a comment below in the disqus forum. If you are looking for a speaker on an Apple development topic or need help with your current macOS app project, feel free to contact me at our form here.

Have you ever had a difficult time getting all the correct sizes rendered for your graphics when you are developing an app in Xcode? 1x, 2x, 3x, 1x 60 x 60, 2x 60 x 60, etc...

Well, that's why we developed Speculid for the Mac. Now you can take your scalable vector graphics and large raster images and render them to all their correct sizes as part of the build process. You create a small json file:

{ "set" : "Assets.xcassets/Raster Image.imageset", "source" : "layers.png", "geometry" : "128" }

or

{ "set" : "Assets.xcassets/iOS AppIcon.appiconset", "source" : "geometry.svg" }

It creates the appropiate png or pdf files for your Image Set or App Icon Set. based what is setup in the Asset Library Speculid is currently available on GitHub as well as Homebrew. For more details take a look at the ReadMe on GitHub and join us on gitter if you have any questions and let us know what you think.