StartSe - Modernizing the base of an app that cannot stop
Evolution and technical migration of the StartSe event app, already published and in use, without interrupting the conference calendar.
An app already live, and it had to stay live
When X-Apps joined the project, in 2019, the StartSe app already existed, was already published on both stores and was already used by attendees of the company's conferences. This was not a greenfield project, and that was exactly the difficulty.
The app ran on React Native 0.55, a version that does not move on its own. The technical assessment was blunt: getting to 0.60 meant rebuilding the project structure, not running an upgrade command.
Meanwhile, the StartSe calendar would not wait. Ten events were mapped as milestones in the schedule, each with a fixed date, each needing the app working on the day.
The challenge
- Modernize the technical base of a production app without breaking the people who already had it installed. Share a repository with the client's own technical team, working at the same time. Build against APIs that were being written in parallel and sometimes returned errors or came incomplete. * Fit a contract of monthly hours with one release per month against an event calendar that was not monthly.
Store ratings, before and after
The starting point is on record: in February 2019, at the beginning of the work, the app sat at 3.5 on iOS and 2.4 on Android.
Today the same app, published as StartSe: Conhecimento do Agora, sits at 4.8 on the Brazilian App Store, with thousands of ratings and new versions shipping regularly.
It is worth being honest about what that number means. Seven years separate one from the other, and the product went on with StartSe's own team, who have maintained it ever since. What X-Apps did was the part underneath: leaving the base on a sustainable version, with navigation, builds and styles in order, so that continuity was possible at all.
An app stuck on an old framework version does not get new features, it gets patches. Leaving 0.55 is what unlocked the years that followed.
The migration, run as a project and not as a command
Moving from React Native 0.55 to 0.60 was treated as what it was: a structural rebuild, migrating components and assets into a new project.
It dragged along a set of changes that were not optional:
- Navigation swap. react-native-navigation was not compatible with the target, so the whole application moved to react-navigation. Both builds fixed. Every native dependency had to be relinked, runtime errors corrected on iOS and Android, and a readme written explaining how to set up each environment. iOS 13 compatibility, which landed mid-way, plus a fix for custom typography on Android. Style refactor. A constants file reused across the application and styles split into stylesheets, component by component. ESLint errors cleared from the project.
Before any of that there was a more urgent problem: anyone with the store version installed who updated from outside hit a crash on launch. Fixing that path was a precondition for safely updating the whole base.
What was built along the way
While the base was being sorted out, the app kept gaining features for the events.
Attendee networking. People who opt in become visible to other attendees, can request contact and talk, with a push notification reaching the other side. Opt-in throughout.
Attendee profile. Bio, interests, photo and details, with the attendee choosing whether to share LinkedIn and WhatsApp.
Agenda by track. The event agenda was redesigned into tracks, with blocks and sub-blocks and the ability to favourite talks.
Content and news. Paginated listing, read inside the app itself.
Push that leads somewhere. Notifications are intercepted even with the app closed and routed by deep link to the right action.
Visual identity. Icons converted to an icon font and the brand typeface applied across the app, including fixing how it loaded on Android.
Stack and practices
- React Native, from 0.55 to 0.60, with react-navigation and Redux. OneSignal for push notifications, with deep links for routing. Native camera and image cropping for the profile photo, with the SDK and Gradle version conflict resolved so Android would compile again. Sign in by email, Facebook and LinkedIn. Client REST API with token authentication. Homologation builds shipped every cycle, with QA on sign-up and sign-in across all three providers before release. Backlog prioritized by the client, with a dedicated form for them to file tasks and defects.
Working inside the client's team
StartSe had its own developers in the same repository. That changes how you work: areas of the codebase had to be agreed to reduce conflict, and finished work did get rolled back because of overlap.
X-Apps also supported the other side. When the client team's environment would not run the project, a call was set up to configure Android and iOS, and the environment documentation was written into the repository.
Is your app stuck on an old version?
A production app that cannot move versions becomes compound debt: every month without migrating makes the next migration costlier and closes feature doors. That move can be made without taking the product offline, and with the client's team alongside.