logo-colorful

Smart Import Feature for my app “Swiva”

Von am 10.06.2026

For this project, I worked on an AI feature for Swiva, my React Native app for saving activities, places and ideas. The basic idea of Swiva is simple: users collect things they want to try, organize them in lists and later swipe through them when they do not know what to do.

One feature we had planned for a longer time was sharing links directly into the app. For example, a user sees a recipe on Instagram, a restaurant on Google Maps or an activity on TikTok and shares the link to Swiva. The app should then create a useful activity from that link, with a title and a short description.

At first, I thought the main challenge would be the AI part. But during the project I realized that a much bigger part was actually getting good information from the shared links.

The real problem: getting the content

Before the AI can generate a good activity, the app needs useful input. For that, I used two general strategies and one special case.

The first strategy is Open Graph metadata. This is the information many websites use for link previews, for example when a link is shared in WhatsApp. It often contains a title, description and image, which can already be enough to understand the basic content of a post or website.

The second strategy is oEmbed. This is used by platforms like TikTok to provide information for embedded content. In some cases, this gives better structured data than normal page metadata.

Google Maps was more difficult. The official APIs are based on place IDs and structured requests, not just random shared Maps links. Also, Google has strict rules around scraping. Because of that, I did not scrape the page directly. Instead, I tried to resolve the link and extract the place name from the final URL when possible.

I also decided to send these metadata requests from the app instead of my backend. If the app scales, I do not want my server to send too many requests to platforms like Instagram or TikTok and risk rate limits or IP bans. Sending them from the app distributes this better and keeps the backend simpler.

On-device AI and fallback

For iOS, I used the Callstack React Native AI package with Apple’s on-device AI capabilities. This worked well and was quite easy to use, because the API is based on the Vercel AI SDK.

My original plan was to also use Google ML Kit GenAI for Android. But the support I wanted in the React Native AI package was not available yet, and I did not want to build a custom Expo module just for this. Since I had already proven the on-device concept with Apple, I used a cloud fallback for Android and unsupported devices.

The fallback sends a request to my backend, which uses a Gemini Flash-Lite model to generate the activity. At first I used Gemini 2.5 Flash-Lite, where the results were comparable to Apple’s on-device model. Later I tested Gemini 3.1 Flash-Lite, and I was much happier with the generated titles and descriptions.

What I learned

My original goal was to compare on-device AI and cloud AI and see if the quality could be similar. I did not fully reach that goal, because the newer cloud model gave better results for my use case.

Still, the project was a useful experiment. I learned how to use Apple on-device AI in a React Native app, how to build a fallback strategy and how important link metadata is for this feature.

For Swiva, I currently think that one cloud strategy is probably the easiest solution to maintain. Gemini Flash-Lite is cheap enough for this use case, the results are more consistent across devices, and the architecture is simpler than maintaining separate strategies for iOS, Android and fallback.

On-device AI is still very interesting, especially for privacy, offline usage and reducing server costs. But in this case, the simplest and most stable solution might be the best one

Check out the feature by downloading Swiva here: https://swiva.app/download

Sources

Beitrag kommentieren

(*) Pflichtfeld