"eees"; another SwiftUI app
The past couple of weekends, I've been hard at work to build a second app using Apple's latest and shiny tools. I'm speaking, of course, of SwiftUI & combine.
Whenever I build something, I try as much as possible to draw it from real personal needs. This allows me to stay motivated and on course for the long run and not abandon the project like so many dusted and forgotten ones.
What's it about
Well, I am a guy who has a sweet tooth and a big mouth for anything sweet: cupcakes, donuts, cakes, or anything in between. I'm also a practicing Muslim(with a beard or a rather "beard-ette" to be quite accurate), so I have a dietary restriction where eating pork is a big no-no. The number of times I have to pull up my phone to search for a "is E-number halal" is innumerable.
Halal: in Arabic, just means permissible to consume, islamically speaking
The search result is either inaccurate or outdated, and that's frustrating. So instead of searching on the AppStore for a probable solution to my problem like normal human beings do, I decided to create my own app for this purpose.
Food additives, also known as “E Numbers” in the EU, are substances used to enhance the appearance and flavor of the food and prolong its expiration date. Some are safe, but some can be very dangerous and cause side effects, allergic reactions, or hyperactivity.
eees (clever name, I know) helps you make knowledgeable decisions about what food to buy.
Whether you are a vegan, Muslim, or any other person of faith, this app will help you abide by your dietary restrictions.
Some ground rules
Before delving into actual coding, I wanted to challenge myself and put some rules to abide by:
No need to have some backend service or a distant database to manage the data. It's hectic enough to maintain one single code as it is, let alone manage another one to store all of the additives.
So for this one, I opted for Realm, a NoSQL database recently bought by MongoDB. It is way faster than the competition, offers schema versioning and an uncomplicated migration mechanism. To top it off, they have amazing documentation that covers pretty much everything, so there's no need to StackOverflow" anything.
Shipping a fully-fledged app from the get-go wasn't an option here. First of all, it's not possible with the limited fixed time that I have. So let's create the bare minimum for a usable product first, and other planned or new features will emerge from the daily usage.
The fewer taps, the better
I don't want the user to tap on multiple buttons or visit the detail screen to get what he wants. One single screen should be more than enough to view the food additive and its information. This is driven by the fact that I want to have the required information as quickly as humanly possible.
A master screen contains everything, from the code and the name of the additive to its information. The second part is hidden by default. The user has to tap on the desired row to expand it with a little fun animation.
Drop it; You are not a designer.
This is a hard-hitting point that hits hard and deep. I'm not indulging myself here (I swear 😉), but I'm that developer that spends a monumental amount of time polishing and redoing over and over again the design of an app. I even lose motivation and halt the project because I can't crack the perfect design.
SwiftUI already offers many system-like UI components ready to be used, so no need to reinvent the wheel here, as they say.
I sent out the app to AppStore for review. Hopefully, it will be out by today or tomorrow. I'll add the link once it's published.
Here it is https://apps.apple.com/us/app/eees/id1584679617.
It took Apple two days to accept my app. Their rigid guidelines, especially for the health & fitness section, were meticulous regarding every meta information of the app, like resources used and the necessity of a disclaimer in the description box.
If you have any feedback on improving this app in any shape or form or need to report a bug, please reach out to me on Twitter. This is the simplest way for now. Maybe I will create a public dummy Github repo to centralize issues in the future.