My iOS App Creation Process — Part 2

Photo by Fotis Fotopoulos on Unsplash

In Part 1 of the series, I outlined my overall approach to iOS development. Here’s the outline of the significant steps as a reminder:

1. Develop user personas and associated user stories
2. Detail the Desired App Features and Requirements
3. Determine Best App Architecture
4. Determine the minimal viable product (MVP) for the initial app release
5. UX design (SwiftUI)
6. Data Modeling (JSON)
7. Coding and Testing
8. Preparing for iOS App Store Submission
9. Develop plans for a future version to implement features that didn’t make the initial MVP for release

In this article, I will focus on the third and fourth bullets to offer insights into how I determine the best app architecture and decide on the MVP.

Determine Best App Architecture

Photo by Tobias Keller on Unsplash

I have a standard set of questions I work through with my clients to uncover the appropriate architecture for a given app. Here’s a small subset of these questions:

1. Does the app need to be available on only iOS or both iOS and Android?
2. Does the app’s content need to be available on the web?
3. Does the app make use of Location-based services?
4. Does the app display a map view?
5. Does the app need to access/retrieve/publish information from/to an online service? If Yes, is there an Application Programming Interface (API) for the online service?
6. Does the app require user authentication to access or perform actions under the API methods?
7. Does the app need to store user defaults?
8. Does the app need to store data on the device for reloading later, such as on the next launch? If the app stores data or user defaults, does that data need to be synchronized to other devices the user utilizes?
9. Does the app use Bluetooth networking for any of its functionality?
10. Does the app require any encryption of its content, including storage of defaults?

Using the above questions and basing my app on the latest for iOS14, I chose the Model-View-ViewModel (MVVM) design pattern. The MVVM pattern is appropriate given the reactive nature of the SwiftUI and Combine frameworks from Apple.

Model-View-ViewModel (MVVM) Design Pattern

The Flickr API does not require user authentication for only returning the Interestingness photostream, but it requires user authentication to manage a user’s Flickr Favorites. Therefore, I need to implement OAuth User Authentication and, in particular, OAuth 1.0 to meet the Flickr API user authentication requirements. To implement an OAuth 1.0 authentication functionality, I will need to use Apple’s CommonCrypto encryption framework for the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm 1 (SHA-1).

The app will not store any photos from the photo stream other than simple caches to limit mobile data usage. Therefore, there is no need for Core Data framework. Note: I could use Core Data as a means of caching photo data and decrease the overall data usage of the app. However, I plan to use a Swift library to implement the photo image data’s caching and avoid the coding to implement my own custom caching.

The Flickr API returns information about photos and other related information in JSON format. Therefore, JSON Codable will be used to properly decode the API results for use in the app’s data model.

The app will need to implement both Core Location and MapKit frameworks to enable location-based photo streams and the subsequent display of specific photo locations on a map.

Here’s the initial app architecture I created based on the requirements and discovery questions above:

Initial App Architecture Diagram

I’ll share the specifics around the MVVM in an upcoming article in the series.

Determine MVP for Initial App Release

My approach to defining a minimal viable product (MVP) is relatively simple:

1. Group the app requirements under the appropriate architecture components
2. Implement at least one (1) requirement from each grouping to build out the app’s foundational structure.
3. Review the development scope for the MVP against the complete set of documented requirements. The review helps ensure future development work builds on a solid app foundation and avoids an all too common event where a developer must tear the app’s code apart to additional functionality for requirements not part of the initial MVP.
4. Ensure the MVP is meaningful to the app user. In other words, the user must have a positive user experience with the MVP version of the app. For example, you wouldn’t choose the implement only the settings screen as part of the MVP for a photos app. You would want to ensure the screen(s) for the photos would be in the first release’s MVP, even if you needed to forego the Settings screen initially.

Based on my MVP process, I defined the initial MVP scope as follows:

• View — Photo Grid that can display any of the photo streams
• View — Photo Details for an individual photo, including a map view of its location if that data is available
• View — Settings to allow for the user to change the appropriate settings, including authentication with Flickr.com
• ViewModel — PhotoStore which handles the data binding with the views and communicates with the models
• Model — Photos to represent the photo streams
• Model — Photo to represent an individual photo
• Model — PhotoDetails depict details of a particular image such as the photographer, image title, image date, among other information.
• Model — OAuth service to perform authentication with Flickr API
• Model — Various Flickr API models to support API actions and errors

In summary, my MVP will consist of at least three (3) screens/views, one (1) view model, and multiple data models. In my next article, I will detail the approach I use for UX design and data modeling.

Until next time, stay safe and keep learning!