Disclaimer: This was written within the first week of SwiftUI being released. Some of this content might be outdated at the time of reading.

📦 Source code for this project is linked at the bottom of the article.

With SwiftUI being just released, everyone has been really excited and focused on (re)building their nice UI using it. However, not many have dug deep into building and handling the lifecycle of “real world” app — which primarily consists of fetching data and displaying it in a list.

This article will dive into the basics of maintaining state throughout the “real world” app lifecycle. This will include:

• Using BindableObject + URLSession to request and decode JSON payloads into Identifiable models.
• Gracefully handling loading and and error states using a generic LoadableState enum.
• Conditionally displaying View elements based on state.
• Fetching and displaying images from a URL.
• Adding UIActivityIndicator as an unofficial View element.

The demo app

For the purposes of this article, I will be building and app which catalogues a store’s products. The JSON API used is in the following format:

The UI of the app itself will be simple — displaying the image, title, and body of each product in a row.

Models

With the API laid out above, we can represent our data using the following models:

It’s important to note that any model which contains UI data must conform to Identifiable. These will also need to conform to Decodable as they will be constructed using JSONDecoder when parsing the network responses — hence the property names and types matching those in the API.

Stateful list rendering

The basis of our stateful list rendering will revolve around this generic LoadableState<T> enum. The fetched case has an associated value of a Result type— this will contain either a success or a failure response.

This state represents three cases:

• .loading: Awaiting a network response.
• .fetched(.failure(FetchError)): The network response contained an error, where FetchError represents a description of the error.
• .fetched(.success(T)): The network response returned successfully with a payload, where T represent the model type.

Usage in a View Builder

From this state, we can display the relevant content to the user. Ideally, we would switch over this enum in the body of our View and return different View elements accordingly — but, at least in the current SwiftUI beta, this is not possible. Xcode will show you compile errors such as,

Closure containing control flow statement cannot be used with function builder ‘ViewBuilder’

when conditionally displaying view elements, or,

Function declares an opaque return type, but the return statements in its body do not have matching underlying types

when different View types are returned conditionally.

To get around this issue, SwiftUI provides a wrapper on any View object to be used such that there is only one underlying type being returned — appropriately named AnyView.

With this AnyView wrapper, our body can be kept slim and the logic can be extracted into this stateContent computed property. While loading, we’ll show a spinner in the view (👀 have a look at the bottom of this article for implementation details). If the response contains an error, we’ll show the error description as plain Text, otherwise we’ll show the list of products. We can wrap this all in a NavigationView named “Products” in the body for a finished look.

Fetching data

SwiftUI introduces many new tools — one of those,BindableObject, serves data between a model and a view. In this BindableObject class, we will perform a URLSession network request and parse the results into a LoadableState. If no errors occur, JSONDecoder is used to parse the data into its respective models. The state, initialized as .loading, will use PassThroughSubject (available through BindableObject) to send an update to its listeners whenever it is changed. Views become listeners for these updates using the @ObjectBinding property delegate, as seen above in the ProductListView.

Rendering images from a URL

As the JSON API used returns image URLs, we’ll need to convert those to UIImages. A similar approach used for product fetching can be used here, however, rather than sending updates in the form of a state, we will send Data.

Using this data, we can construct LoadableImageView — a stateful image View. A spinner will be show in this view while awaiting image data.

That’s all! With this, we’ve built a stateful list that fetches data and images from an external source. 🎉

Bonus: ActivityIndicator View

SwiftUI comes with a lot of out-of-the-box View elements, but have yet to port a select few. Luckily, the UIViewRepresentable protocol enables us to build out the missing ones. Use this snippet to show a spinner on any View:

📦 Source code:

schmidyy/SwiftUI-ListFetching

Thanks for reading! Feel free to follow me on Twitter and Github for more like this 👨🏻‍💻

Stale data sucks. With the help of Firebase’s data subscription model, all the data shown in your app can be up to date and consistent across. This article will go over how we built a realtime contacts app using Firebase and FunctionalTableData (FTD) — a functional approach to maintaining view states.

Realtime Functional Table Data is a basic Contacts app built with Shopify’s Functional Table Data and Firebase. The idea is simple; each screen subscribes to a model in Firebase and is notified with realtime snapshots every time it’s updated. Each snapshot is decoded client-side and passed to Functional Table Data which compares it to the previous state to insert, update, and remove sections and cells that have changed.

Check out the Github project here: https://github.com/Campbell-Scott/RealtimeFunctionalTableData

Getting started

Detailed instructions on how to get Realtime Functional Table Data up and running, along with configuring Firebase are available in the README.

With this, run the RealtimeFunctionalTableData target on any device!

Project Structure

As you might notice, this project isn’t built using the traditional Model-View-Controller design pattern. Functional Table Data helps separate view-level logic and concerns from the view controller. FTD facilitates this React-like view building with its efficient state diff’ing algorithms and its functional approach to maintaining view states. Here are the four component’s responsibilities in each view:

1. the state: responsible for maintaining the current source of truth of the view’s data.
2. the builder: responsible for deciding which data from the state to display, in what style, and how to handle action events.
3. the view controller: responsible for performing or delegating actions passed from the builder, then updating the state accordingly.
4. the service: responsible for performing asynchronous tasks (such as network requests) and reporting the results.

There are three views in this demo contacts app; List, Add, and Details. As you’ll see nested under Sections in the project, each of these have a respective View Controller and Builder. Since the state of these are so small, they currently live in the Builder files, but it wouldn’t hurt to extract them.

Let’s examine how the List view is built and organized! As previously explained, you’ll notice the View Controller (VC) doesn’t know anything about the User or the view elements. The VC keeps reference to a FunctionalTableData object which will be managing our table view and diff’ing when needed. The state for this view is an enum with two cases; .loading and .finished(result:). As the content shown on this list needs to be fetched via a network request, we initialize the state as loading, then update the state to finished when the up-to-date User object is received.

Whenever the state is updated, the render(state:) method is called with it. This method invokes the List Builder for TableSection objects, then uses FunctionalTableData’s renderAndDiff(sections:) to update the view with the new, up-to-date, data.

When the builder receives a new state, it decides what the list view should display based on its enum value. If the state is set to .loading, the builder will return a spinner cell. If the state is set to .finished(result:), the builder will return an array of ListCells, each representing a contact. Every cell is represented as a CellConfigType object, which holds its view, state and actions.

Cell actions (such as selection, or a textfield value changing) in FTD are protocol-based. Typically, a protocol with the Actionable nomenclature will be defined with a function representing each action to be used in that builder. Respective VCs simply conform to these protocols and define the behaviour for each action. In the case of the list view, one action is defined for the selection of a contact cell which pushes the Details VC of that contact.

Services are responsible for performing asynchronous/non-deterministic tasks (such as network requests) and reporting the results to a concrete instance of the ServiceDelegate. Services are vended to their consumers through the ServiceProvider. Since consumers communicate with every Service through a shared interface, each service can hide its own implementation details. This allows a developer to swap in any new Service implementation. For example, the FirebaseService in RealtimeFunctionalTableData implements subscribeToUser() by subscribing to a User document in Firestore and calling its delegate every time it receives an updated snapshot. Another Service might implement this by fetching a User from CoreData or a Realm Database, etc.

With all this, our app never needs to worry about stale data being shown! All in all, this app features:

• Realtime syncing and rendering — no pull-to-refresh!
• A functional approach to maintaining view states
• Programmatic view layout — no more interface builder!
• An agnostic network layer which accepts any service

Come help us build Functional Table Data!

Careers and Jobs at Shopify

Building a Realtime iOS App Using Functional Table Data was originally published in Shopify Mobile on Medium, where people are continuing the conversation by highlighting and responding to this story.

After spending the summer working at Shopify as an intern on the iOS team, I thought I’d share the hiring process, technical challenges, as well as what I learned during my time there. Overall, this summer has been an incredible experience where I got to meet amazing people, work on really cool projects and grow tremendously as an individual.

The hiring process

Background and disclaimer; I had roughly a year of professional iOS experience before applying for the internship. The current process will likely have changed from the one I describe. All in all, it took roughly 3 months between applying and getting my offer.

As many already know, the hiring process at Shopify is fairly unique. This begins with the application, which took me nearly 5 hours to complete. It involves answering some short form questions, building my own Shopify store, and building a small iOS app following the provided criteria. The app was a simple product list view with data and images pulled from a REST API endpoint, and for bonus points, add product pages and search functionality. I enjoy doing these types of challenges because I can do them on my own time and in my own environment.

The next step was the infamous Life Story interview, which is essentially an hour long video chat with a recruiter to talk about your background and how you got into the field you’re applying for. This isn’t a technical interview, although, during mine, we discussed my past projects and the tools I used to build them. I believe anyone can pass this interview as long as they show enough authenticity and passion for what they do.

The final step for my internship hiring process was a 2-part technical interview. I’m fortunate enough to be living in Ottawa (where Shopify’s headquarters is located) which gave me the opportunity to go on-site for this portion, but typically this step is also done over a video chat. The first part was a project demo where I showed off an app I built on my own time to two senior engineers and went through the code and architecture choices I made. The second part was a technical question along the realm of system design and scaling.

A very long couple of weeks later I got the call with my offer 🚀

For a more in depth description of the intern hiring process, I strongly recommend having a look at one of my fellow interns article on the subject.

How I got an internship at Shopify

Technical hurdles

There’s a lot to be learned when starting on a new team — especially on one of such large scale. Fortunately, each individual contributor at Shopify is given a mentor — they are an incredible resources when joining a team as they will likely have a lot of context on the work you do and will be able to answer your questions. For me, one the biggest technical challenges I had when starting was adapting to building views fully programmatically. Previously, most of the views I’d built were done in Interface Builder (i.e. Storyboards & XIBs), which, in hindsight, is only sustainable for small-scale apps (merge conflicts suck 🙅‍️).

Having said that, another big change in coding styles for me was no longer using traditional UITableView / UICollectionView for building views. Since almost the entire app is some sort of table view, it wouldn’t make sense to not use a more functional approach. That said, Shopify uses their open source FunctionalTableData (FTD) framework for constructing views. FTD facilitates building views by allowing state-based view rendering (this brings react-like thinking to mobile!). This framework heavily revolves around the Builder design pattern which, in this case, segregates each view into 3 components;

1. the state: responsible for maintaining the current source of truth of the view’s data.
2. the builder: responsible for deciding what data from the state to display, in what style, and how to handle action events.
3. the view controller: responsible for performing or delegating actions passed from the builder, then updating the state accordingly.

That likely doesn’t make a whole lot of sense right now, and trust me, it took me awhile to understand what was going on — but it works so well when properly executed. For example, let’s say you want a cell that has a label on the left, and a checkmark on the right which is displayed conditionally, all you would need to do is tell your builder to create an instance of your checkmark cell template and pass data from the state it needs — such as the label’s text, a boolean whether or not the checkmark should be displayed, and an action block to be execute when the cell is selected. You can also optionally provide a ton of customizations for the cell’s style to perfectly match the design requirements. This approach has completely changed the way I think about building views and was incredibly eye-opening to me when I finally understood how all these working components were pieced together.

In addition, all of my past experience when building an iOS clients with a network layer was either through REST API, or some sort of database integration like Firebase. However, Shopify changed that by introducing me to GraphQL (GQL). GraphQL is a query language that allows clients (i.e. iOS, Android, Web) to request and mutate exactly the data it needs for a given component. This allows for extreme flexibility when building views across multiple clients, and is especially beneficial on mobile clients in terms of saving network bandwidth for the user. I won’t go into many details here, but there are many great resources available to teach beginners about the gist of GQL. I spent a decent majority of my time this summer working on building GraphQL queries and mutations which was a new and challenging experience for me. In order to work with GQL, it requires knowledge of this new query language, such as understanding the syntax and its components — like fragments. Of course, with everything new, it takes time to learn, but really pays of to understand.

Another thing to expect when working as a developer is doing code reviews. Shopify has a really good culture for their CR process where their developers typically dedicate up to a quarter of their day for doing reviews. This was a fairly new process for me as reviewing code was never a top priority during my previous day-to-day schedule. In order for me to properly set aside this time, and get in the habit of reviewing pull requests (PRs), I started scheduling 30 to 60 minute blocks in my calendar purely dedicated to doing code reviews. This dedicated time spent reading and reviewing my teammates code helped me understand how they approach problems, and, in turn, helped me improve my own coding practises. At times, it felt like my PRs were never going to get merged because of seemingly never-ending nit-picky requests, but, in hindsight, all of those little details go a long way when maintaining such a large codebase. Fortunately, with this strong culture of code reviews comes high standards of code.

On a less technical side, since Shopify is such a large organization, a lot of soft skills are needed to work efficiently — such as communication. There were times where I would be working on a feature that would require certain fields to be available for me from the server that weren’t already available. This would normally be fine — just ping the team which “owns” the relevant fields and try and borrow one of their backend dev’s time to get those exposed on GraphQL. However, when working on new features, it wasn’t always obvious if there was a team that owned the data you were looking for. This caused what seemed like a never ending pursuit to find someone with the necessary context to get what you needed. Dealing with this can be frustrating, but definitely taught me a lot about working on projects which spanned multiple teams.

TL;DR — Takeaways

Often the biggest takeaways from a work term are concepts not taught in school — such as being an effective team member. What stuck with me the most was the idea of writing code for others, not yourself. A common misconception for programers (especially found in Junior developers) is that the code they write should be as dense as possible, and use all the new and fancy APIs to impress their coworkers. In fact, this coding practise has a negative impact on your team, and is not specific to iOS developers either. After all, the ultimate goal when on a team is to write code which will be easy for others to read (and maintain).

Thankfully, Shopify provides an amazing environment for growth and supporting employees throughout the learning curve. They host weekly developer talks, team show and tells, community developer events, company-wide summits with workshops and so much more.

If you’re up for the challenge, consider interning at Shopify!

Internships at Shopify - Paid Internship Program

If you have any questions about the process, or enjoyed the article, feel free to reach out to me on Medium, Twitter, or Github ⭐

Standard iOS components can get boring… Luckily, with Swift, customization is available everywhere! This article will demonstrate how to use a custom image for your navigation bar, while still maintaining all the functionality provided in a Navigation Controller. 🚀

TL;DR: Clear the default nav bar image provided by Navigation Controllers using a bit of code and position your image in it’s place by constraining it to the view’s top, leading, and trailing anchors (be sure to not constrain to the safe area).

1. Creating the custom header image

Chances are the custom navigation bar header you have in mind for you app will need to be created manually. There are many ways to go about doing this, but the simplest for my needs could be done using Sketch. Using the vector tool, I was able to create the design I had in mind within a couple minutes. The dimensions here don’t really matter because of the excellent export presets Sketch has by default (the iOS preset provides standard, @2x and @3x sizes Xcode asks you for).

2. Clear the default Navigation Bar image

Assuming you already have a view controller embedded in a Navigation Controller, the next step is to strip the nav bar from the default provided header image. This is fairly straight forward, and can be done in a couple lines of code. Here is the function I use to do so; and note — I put it a struct for reuse purposes, but this is optional.

And this is how the method is called from the view controller:

The above code snipet should be called from either viewDidLoad() or viewWillAppear(_:) in order to ensure it is executed before the user sees the view. If you run the app now, you should be able to notice the missing nav bar image. 🔥

3. Insert the custom header image

Now that the navigation bar is clear, we can provide our own image. For the purposes of this article, I will do this using interface builder. This is as simple as dragging a UIImageView onto your view controller, providing the proper image, and setting the constraints.

In order to set the constraints so that the iPhone X doesn’t clip the image, we need to constrain the imageView's top anchor to view's top anchor (not the safe area). In my case, setting the constraints to 0left a small gap along the edges, so a value of -2 should fix that.

Of course, the height constraint will change depending on the image used. and, since my image is dark, I also went ahead and set the large title text colour to white, and the status bar to .lightContent.

At this point, the custom header should work as intended 🎉

4. Handling device sizing and orientation

You might notice the header image looks fine on the iPhone X, but on any other device it looks way too big. This is because there is a gap between a view's top anchor and a view's top safe area anchor on the X. Luckily, can easily adjust the height of the image through an IBOutlet reference to the heigh constraint of the image view. Full device sizing can be found here. Place this code in the same area we clear the navigation bar default image:

You might also notice the height of the header image height is way too tall when rotating the device to landscape. This can be easily handled in the willTransform(to:with) method provided in the view controller.

I didn’t include it in my examples, but this will also work with added bar button items to the nav bar. That’s it! Your custom navigation bar image should now work as intended 👌

Feel free to follow me on Twitter and Github for more content like this 👨🏻‍💻

⚠️ This article is now over a year old and such some code might be outdated.

If you plan on implementing a map view in your iOS app, chances are you’re leaning towards using Google Maps, as opposed to Apple Maps — and I don’t blame you. Mapping apps have two common uses: providing directions, and indicating specific locations throughout the map. If your app will include the latter, map markers are the go-to tool to facilitate it. Info Windows are the views presented when a user taps on a marker — and because this is Swift, there’s a lot of potential functionality and information that can be presented in these views. While the SDK guide provided by Google does go into great detail on every individual map component supported, they don’t make it obvious as to how to piece it all together. Now, as I learned while working on my first map-centered app, not only are there no obvious tutorials or guides provided by Google themselves, there also aren’t any complete and polished guides available anywhere online.

Assumptions

Google Maps should be implemented and working in your app already. If you need help implementing Google Maps itself, there are plenty of easy to follow guides available throughout the web, and by Google themselves here: https://developers.google.com/maps/documentation/ios-sdk/start

If you plan on implementing dynamic info windows, your App should also be backed by a database — in my case, I’ll be using Firebase. The database entries will store the coordinates of all your markers, as well as some data related to it.

In this guide, I’ll be going through creating a custom XIB file for your markers, displaying marker data in its UILabels, and handling button press events done on the marker. This will be done using Swift 3.

1. Creating the Custom Marker View

The first step is creating a new view file, which I named MapMarkerWindowView.xib. The XIB file view should be resized to your preferred info window size, and should hold all of your desired UI elements, such as UILabels, UIButtons, UISwitches, and anything else you might want to include. Don’t forget to lock all these elements into place using constraints. In this example, I have three labels, and one button.

2. Making the Associated Class File

Next, create a new Swift file that will contain the class to control your view file, mine is named MapMarkerWindow.swift. This class should extend UIView, and have IBOutlet references to your UI elements. If you include elements in your view which require event handlers, such as UIButtons, reference these in your class with IBActions. In order to let your MapViewController class know these events have been triggered, you’ll need to create a delegate protocol along with event handling methods in your MapMarkerWindow.swift, and implement it in your MapViewController class. Additionally, create a public class method to instantiate the XIB file you’ve previously created. This will be required later when assigning the custom info window to the markers.

3. Loading the Marker Data from your Database

Moving to the class that manages your Google Maps view, you’ll need to gather a dictionary of data relating to each marker you want to place on your map — this must include coordinates for the marker location. As previously mentioned, I’m storing my marker data on Firebase. Retrieve your marker data whichever way you need to, and make sure the latitude and longitude values are readily available. In my case, I will load all the data for each individual marker and store in a dictionary I call spot. Once you have the data, you’re ready to create the map marker — we’ll do this on a the main thread to offload the computations from the UI thread. At this point, you can use an image as a custom marker image and color it as you desire. Assign the position property of the marker to the coordinate values you previously loaded, and don’t forget to assign the userData property of the marker to the spot dictionary containing all the marker data. This step is important as any data you want to display on the info window will need to part of this userData dictionary associated to the marker. You should call this method from viewDidLoad.

4. Implement the GMSMapViewDelegate methods

Have your MapViewController extends from the GMSMapViewDelegate protocol. This will require you to implement a few methods, but first create two class properties:

private var infoWindow = MapMarkerWindow()

fileprivate var locationMarker : GMSMarker? = GMSMarker()

Next, create a function to return an instance of the custom view class you created

In viewDidLoad, be sure to assign self.infoWindow = loadNiB().

Now, we’ll implement some GMSMapViewDelegate methods. The primary method, which will allow you to get all your map data displayed on the info window, is the didTap marker method. Using the marker parameter passed in, we can access all of that markers data through marker.userData. Set your self.locationMarker class property to be this marker — this is so that we can later handle moving the info window appropriately if the map gets moved. We also want to reset the self.infoWindow class property to be loadNiB() again. At this point we can do any UI element configuration to the info window, such as adding a corner radius, or lowering the opacity. We also set the text of our info window’s label(s) here using the data provided in marker.userData. We also want to place the center point of the info window’s view to equal the center point of the marker here. A negative Y value offset will be required to place the info window above the marker.

The other two delegate methods from the GMSMapViewDelegate protocol we will implement are didChange position and didTapAt coordinate. If the map view was moved while an info window is open, we want the info window to properly reposition itself to stay on top of the marker it was sourced from. Additionally, if a user taps elsewhere on the map, we will dismiss the info window from being presented.

At this point, if we run our app, the info window should be presented with its appropriate data.

5. Handle event triggers from the info window

If we want to execute a bit of code from the MapViewController when a button on the info window is tapped, we simply implement the MapMarkerDelegate protocol in that class. This will force us to call the didTapInfoWindow method we defined in that protocol. From here, we have full access to that markers data. This can be useful if we want to push a new view controller that requires the spots information.

That’s it! This should piece together all the working parts required to get a custom info window for your maps markers.