Schengen Calendar App (iOS)

Abstract

An app to keep track of how many days you have spent in the Schengen Zone.

Reason

Back in 2022, my partner accepted a job in Luxembourg. We lived together in the UK at the time and it had always been her passion to work in the EU. We packed all her belongings into the car and drove to Dover to catch a ferry to Calais. At Dover we passed through passport control. My partner is a citizen of the UK as well as France, but I only had a British Passport. French border control took my passport and stamped it, declaring that I had entered France on that particular date. They also scanned my passport, which I presume also records the same in a government system somewhere.

At the time, it didn't cross my mind, but although that wasn't the first time I had traveled to the EU since the UK left the EU (Brexit), now that my partner was moving back into the EU, this would become a lot more common for me.

The Golden Rule

The UK has an agreement with the EU that can be summarised as follows:

UK citizens can spend up to 90 days in any 180-day period within the Schengen Zone without a visa. This applies for tourism, business, or short visits. The 90 days are cumulative across all Schengen countries, not per country, and the 180-day period is rolling, meaning you must track your days carefully.

As I had only been traveling to the EU previously on vacations, I would now be wanting to spend as much time as possible across the channel.

Initial Concept

App that can keep track of how many days, in the last 180, I have spent in the Schengen Zone.

Trip Tracking

This was the initial idea. Keep track of each trip, a start date, end date and then create some mechanisms that could give me a score, or number of days that I had spent in the zone.

In the window?

There are6 possibilities for each trip:

1. The trip started and finished more than 180 days ago - This trip isn't counted
2. The trip started before the 180 window but finished less than 180 days ago - Some of the days are counted
3. The trip started and finished less than 180 days ago - This trip is counted, in full
4. The trip is ongoing, it started less than 180 days ago, and will finish in the future - Some of the days are counted
5. The trip starts and finishes in the future - This trip is not counted
6. Albeit unlikely, the trip could have started more than 180 days ago and still be ongoing

So what days count, and which ones don't?

If someone spends even a second in the Schengen Zone, it counts as a day. In real terms, if I cross the French border (albeit in Dover) at 2359, it counts as a day.

First proof of concept

The first proof of concept was styled in yellow (not really sure, but perhaps it is because of the yellow stars in the EU flag. I honestly can't remember).

The homepage showed the recent trips, the number of days for that trip and at the top, the total score

At the time, the data was stored using Apple's Core Data storage. This was purely for proof of concept at first and would be swapped out at a later date when I was more happy wiht the UX and the concept

The UI was built using SwiftUI. This was my first project using the framework and I liked how a lot of the heavy lifting was done behind the scenes. I also appreciated the strong documentation on the framework provided by Apple

Evolution

After putting the project down for a few weeks, I picked it back up again, and naturally started totalled fresh.

The second concept was focused more on Apple styling, a simple tab layout and more interactivity. It also focused more on a Calendar approach, rather than a list of days.

The reason for the Calendar approach was to give more value to the user. If I just showed them their current score, today, it would make it complicated to plan further trips etc.

I'd also realised that my calculation methods were very wobbly and often reported incorrect values for the duration of a trip.

Data storage

At this point I wanted to re-visit the data-storage problem. I moved away from Core Data and leveraged something I'd learnt earlier that week about integrating with Google Firestore.

I set up an account, and integrated all the keys etc into my XCode project and began creating functions to store the data etc. It was a new concept to be dealing with "Documents" and leveraging the firestore commands inside my code

I felt like I was heading in the right direction and continued to iterate the design.

Mature

I had learnt about a component called a Sheet which I was keen to see if I could get away with keeping all the UI on one screen, so I implemented it and was starting to like where the concept was taking me

At this point, I was transacting data with Firestore, the math calculations were correct and I was using it whilst travelling back and forward to the Schengen Zone.

Timezones

I noticed some oddities happening when I was traveling to the trip dates and scores.

After pulling most of my hair out, I noticed I'd been naive and not thought about timezones. I was storing the date and time and not converting it properly when I was viewing the same data in a different country. You see 00:00 on Thursday when recorded in (+1h) timezone would be seen as 2300 on Wednesday when viewed in GMT (+0h)

I spent far too long trying to work out how to solve this. Was it the way I was storing the data, or perhaps the way I was parsing it once I retrieved it from Firestore?

After finally working out a solution and handling all the timezone problems in the database interaction, I was happy with the functionality underneath and decided to expand the UI and UX.

Delightful

I wanted to include a homepage that simply showed you your score and an overview of the app. I wanted to add a settings page to let the user choose between a countdown type of number or an accumulative alternative. Finally, I wanted a separate page for the trips list

Publishing

The Apple App Review process was both infuriating and invaluable all at the same time

It took me a good few tries to finally get my app published on the App Store and the process is seemingly not very transparent.

Screenshots

The app failed the App Store Review multiple times as I had to update the screenshots for every change I made to the app. The screenshots had to match pixel perfectly to the app itself. This was tedious as I haven't discovered a quick way to capture all the required screenshots for each build.

Privacy Policy and T&Cs

It had completely slipped my mind that I would be required to create these and was reminded in the notes of another failed app review that it was required.

These had to be hosted online somewhere, so I repurposed a path in my old website to host a basic html version of both the documents.

I quickly drafted some and re-submitted them for publishing.

Success (supposidly)

The app was online. It was visible in the App Store. I had made it. I had decided to charge £3 for the honour of having it on your device. This was some advice I had been given by a friend. It went something like this:

If you want someone to be honest about the problems in something you've made. If you want good feedback, they have to have a reason to complain. Charge them a small amount for the app. If it's small enough, they'll not worry when they purchase it. If it's big enough, they'll let you know you made a mistake

Although this would ultimately reduce the amount of people that installed my app, I wasn't doing it for fame. It's all part of a learning experience

Success (true)

I checked the App Store Connect app a few weeks later to, at my astonishment, people had ACTUALLY BOUGHT my app. Next step, billionaire.