Health Notes has been online since January 2020, and now more than half a year has passed (you can learn about the origins of the Health Notes app from Old Man New Soldier - A Development Memoir of an iOS APP). During this period, I have gained further understanding and knowledge of Swift, SwiftUI, CoreData, etc. Most of the issues and uncertainties I faced during the development of version 1.0 have been resolved.
With the upcoming release of iOS 14, and a desire to organize and apply the knowledge I have learned in a more systematic manner, I have scheduled the development of Health Notes 2.0 and have already started working on it.
Standardization of Health Notes 2.0
-
Features
The current functionality of Health Notes 1.0 can basically meet my personal daily use. During the time since its launch, I have added some new features based on user suggestions. Therefore, there are not too many core functionality additions in 2.0, mainly focusing on two points:
-
Data Types
In 1.0, there are currently two supported data types: a numerical type (recording a single number + date) and an option type (custom option content + date). In 2.0, there are five additional data types, including double numerical type, numerical option type, start time type, etc. Users can record a wider variety of content in life.
-
Data Import and Export
In 1.0, there is already support for exporting data of numerical cards, entries, etc., individually (csv, pdf, xslx). Version 2.0 will provide a unified export entry, and will also offer import functionality. Users will have more options to store and use their data, such as sharing the cards they create with other users or re-importing their saved offline data.
Although it is a major version update, even though there are not many changes in functionality, there will be significant changes in other areas, which will be mentioned later in the text.
Development Environment, Framework
Xcode 12 + SwiftUI 2.0, mainly for the following reasons:
-
Since WWDC 20, I have been tracking and learning about the new features in iOS 14 (most of my recent articles are about this) and the new features provided in SwiftUI 2.0. In the initial planning, I intend to use quite a few new features in 2.0 to complete my own ideas. As iOS 14 fully covers the hardware supported by the previous iOS 13, I believe that the resistance to updating for iOS 13 users will not be too great.
-
Current user base is not large, so there is less legacy to deal with. Since its launch, the total downloads of Health Notes have just exceeded 1,000, which allows me to make major adjustments more freely.
-
Many plans and designs in version 1.0 were not perfect. In the past few months, I have rarely added new features to version 1.0, mainly because the initial structure design was unreasonable and the code was chaotic. Forcibly adding more features would only lead to more hidden problems and hinder future adjustments. Therefore, in 2.0, I decided to make significant changes to the previous data structure design and to rewrite all the code from version 1.0.
-
The issue of data migration. Due to the poor data structure design of 1.0, I plan to make big changes in 2.0, which will pose a severe challenge for CoreData’s data migration. In the minor upgrades of version 1.0’s data, I have already experienced the convenience and uncontrollable dual problems brought by CoreData’s migration mechanism. Although I can solve the problems faced by major structural changes by writing my own CoreData migration code, to avoid leaving hidden dangers and to leave more freedom for future expansion, I decided to abandon the use of CoreData’s migration mechanism.
-
I was already planning to further enhance the data import and export in 2.0, so for 1.0 users, I will provide a safe data migration capability to smoothly transition to 2.0.
As a result: users will have to re-download Health Notes 2.0 app from the app store (not an update over 1.0), and 2.0 will support iOS 14, macOS 11, and above systems. Data from previous Health Notes 1.0 users can be safely and conveniently manually transferred to the 2.0 version.
-
Multiplatform Support
2.0 will support iPhone, iPad, and macOS.
SwiftUI itself provides excellent support for multiplatform, but in order to better utilize the specific features of different hardware platforms, I still decided to make more targeted adjustments for multiplatform support.
-
iPhone use will still be portrait-only, just like in 1.0.
-
iPad use will be landscape-only, with a completely different layout from the iPhone.
-
For macOS, instead of using Catalyst, I will write using native macOS target. Although this increases the workload, it can better adapt to desktop operations, especially by providing a completely different keyboard and mouse interaction logic from touch operations, and adopting layouts and control operations that are more suitable for desktop platforms.
-
The Swift libraries I’ve recently written generally provide cross-platform support.
-
Since I decided to do full cross-platform development (uikit+appkit), there will be more restrictions when choosing third-party libraries.
-
-
Multilingual Support
The text volume of Health Notes itself is not large, so purely from the perspective of textual content, multilingual support is not complicated. However, since it involves a lot of data display, date calculations, etc., I still encountered many challenges when providing true multilingual support.
In the current development version, users can already set the language and time zone in the app independently without relying entirely on system settings.
The main unresolved issue with multilingual support at the moment is related to the loading of Demo data. I hope to find a solution that is less labor-intensive and has a smaller data volume.
Code Structure
Health Notes 2.0 will completely overturn and rewrite the code, one of the very important reasons is that I want to implement an MVVM structure that I find acceptable for use with SwiftUI.
When I was developing version 1.0, I had just come into contact with MVVM, and basically completed it according to the logic provided by others. In actual use, on the one hand, I found many places that I did not understand or found inconvenient, and at the same time, in continuous learning, I also found many traditional MVVM issues that do not adapt well to the SwiftUI framework. In the past few months, I have been studying and researching an MVVM structure suitable for SwiftUI, and these learning results will be fully tested in the development of 2.0.
Xcode 12 offers a SwiftUI lifecycle, with thorough changes from the entry point of the program to App Delegate and Scene Delegate responses. How to design a state machine that is more suitable for Swift 2.0 has been discussed and analyzed in many forums. The structure I am using in development has been adjusted accordingly. And it provides good response support for multiple platforms and languages. At the same time, to facilitate the use of Preview, declarations and injections for CoreData have also been adjusted accordingly.
Afterward, I will specifically write an article to discuss and explore this with everyone.
I will update musings from time to time during the development process. On one hand, to organize my own thoughts, and on the other hand, to provide some reference for other individual developers.
