Back in July, we added foldable iPhone support to our goals for MealPrepPro.

The interesting challenge with iPhone Duo is that the screen can change while you’re using the app. You might open a recipe on the outer display, unfold the phone, rotate it, or resize the app.

Throughout all of that, you should still be looking at the same recipe. Your place in the app should stay intact. The interface needs to adjust without making you feel like you’ve started over.

The work started by making changes to our app startup code.

One app, many sizes

MealPrepPro has grown over almost nine years. Along the way, we’ve built layouts for different devices, added features, and made use of the space available on each screen.

Duo pushed us to revisit those decisions.

We turned to Claude’s recently added Design in Codebase feature. In earlier iterations of Claude Design we found it would often ignore the need to adapt designs for different screens.

Giving it the context of our code was a big breakthrough in terms of the quality of the designs we were getting back.

We started thinking about the elements of the page as “widgets” that would move around based on the space available.

Some screens were good to go - mostly where we’d stuck to Apple’s defaults (such as the settings screen) but other screens required much more work like the recipe view.

In the recipe view, we redesigned the nutritional information section and made it more compact so it could fit neatly beneath the recipe intro.

This solved an issue of a lot of white space and it also responded to what we were hearing from users that they wanted calories and macros listed further up.

Cooking on the iPhone Duo

Cooking is a particularly interesting use case for Duo: a larger display gives ingredients and instructions room to sit alongside each other, so you can refer to both without constantly switching back and forth.

But a folding screen brings its own considerations. Controls need to remain easy to reach, and a button in the crease is hardly convenient when you’re halfway through making dinner.

Making it work, then making it feel right

By early October, we’d drawn a useful distinction between two stages of the work.

First, make the app resize and rotate properly. Keep content visible, preserve navigation, and use the available display without black borders.

Then, refine how each screen takes advantage of that space.

There are plenty of tempting possibilities for a device that can sit partially folded on a counter. But our first priority has been getting the adaptive foundation right, with more specialized layouts as something we’ve considered later in the project.

Tackling this with Claude available to us has definitely made us far more ambitious in what we’ve been able to do. It’s hard to imagine tackling a project like this in the pre-AI coding days.

Part of something bigger

I’m really excited for this update as it adds so many features and upgrades that we’ve repeatedly heard from customers.

With interactive widgets coming to iOS 17 we decided it was a great opportunity for us to update our widgets.

We started by going through the 2023 WWDC sessions:

• Bring widgets to life - WWDC23

• Bring widgets to new places - WWDC23

We also signed up to Apple’s developer labs.

Widgets in MealPrepPro

In MealPrepPro you can log meals by tapping the Eaten button. This also logs the calorie and nutritional information to Apple Health.

Our widgets give you an easy way to see your upcoming meal, log it and track your calories and macros.

Widgets are independent mini apps

iOS Widgets operate independently from iOS apps. They run on their own as mini apps, and often the main iOS app won’t be running at all. You might have quite a few widgets visible all the time on your home screen, and the parent iOS apps aren’t running in the background at all.

For widgets to run independently, they need their own supply of data. Some widgets get data from the main iOS app. Other apps get data directly from the internet.

How the MealPrepPro widgets get data

In iOS 16 and earlier, our iOS app writes data to a file in a shared area. The widget then picks up the data from that shared area when it runs.

To prevent the widget from running out of data, we give the widget enough data to show meals for the week ahead.

With iOS 17, widgets are no longer limited to just displaying data. You can now wire up buttons to trigger actions that might do things such as tick off items in a to do list.

Widget Interactivity in iOS 17

To add interactivity to widgets you use App Intents. The most well known example of app intents is the Shortcuts app.

Intents are pieces of an app's functionality that are exposed to the iOS system.

🤔 Challenge 1: How do we hookup the widget’s eaten button?

For MealPrepPro, we wanted the Widget to have an Eaten button for a meal. This would:

1. Mark the meal as Eaten inside the iOS app

2. Optionally log the calories and nutritional information to Apple Health

However, this task proved to be more challenging than we initially anticipated. We mistakenly assumed that the App Intents feature for Widgets would work similarly to the Shortcuts app. We believed that tapping a button in the widget would trigger code inside the main iOS app to update the app's database. However, this was not the case.

The rules for what a Widget App Intent can do are:

• Can trigger code inside the Widget

• Can trigger code that’s shared between the main iOS app and Widget

• Cannot trigger code inside the iOS app that is not shared with the Widget

In our case, we wanted to trigger code that was exclusively inside the iOS app and NOT shared with the widget. Specifically we wanted to update the iOS app’s database to update the Eaten (true/false) for a specific meal. The iOS app database is not visible to the widget.

Option 1 - Add the iOS database to the widget

The first solution we considered - could we make the iOS database visible to the widget? This would mean sharing the necessary database and model code with the widget.

It would mean moving the app’s database where the meals are logged to the shared area between the iOS app and widget. Our app’s database is based on SQLite (using GRDB), and sharing a database between the main app and a widget extension is particularly challenging and error-prone. The documentation recommends avoiding this approach.

Option 2 - Get Firebase to update the widget

We also considered using Firebase (via the network) to update the widget. However, we wanted to avoid adding complexity to the widget.

Option 3 - Create a new mini “database”

In the end we felt the least complicated solution would be to create a new mini database that would live inside the area that’s shared between the iOS app and the Widget Extension.

• When the iOS app changes the meal plan, it updates this new database so that the widget knows about the change

• If the widget marks a meal as Eaten, it also updates this new database so that the iOS app can pick up the change.

🤔 Challenge 2: Why is my widget button not working?

We hooked up our Eaten button in our widget, put in place our new code for our new mini “database”… and found that it worked sometimes… but not always. Tapping the Eaten button in our widget didn’t always seem to work which was strange.

We assumed this was a bug in a beta version of iOS, so set the problem aside for a while and waited for a new beta. But with the new beta the problem was still there, so we were a bit stuck thinking that we were doing something wrong.

And then on 1st August we saw an interesting post on Mastodon from Michael Gorbach, the Engineering Manager for App Intents, Shortcuts and Proactive Intelligence at Apple:

https://mastodon.social/@mgorbach/110812346248732071

Michael explained that what happens when you tap a button or toggle in a Widget depends on whether the iOS app is running at the time or not.

In our case:

• If the iOS app is running, the App Intent triggered by the Widget runs in the iOS app

• If the iOS app isn’t running, the App Intent triggered by the Widget runs in the Widget

This explanation by Michael explained the inconsistent behaviour we were seeing.

We updated our code to take in to consideration if the app is running or not.

Ready to go 🚀

We’re happy with how MealPrepPro widgets turned out for iOS 17 and looking forward to launching them in September.