Onboarding: Simplifying App Onboarding with Manifest/Plist Upload Feature

[kolharsam]

Background

Currently, the app onboarding process, as per my understanding, in Tramline involves manually filling in fields such as:

• Name: Can be any string (not necessarily the official app name)
• Bundle Identifier: The unique identifier for the app
• Build Number: app’s version code or build number
• Mobile Platform: Either Android or iOS.
• Timezone
• Description: is optional.

While the current process is functional, it can be improved by reducing manual input and minimizing errors, especially for critical fields like the Bundle Identifier and Build Number.

Ref: tramlinehq/tramline#307

Proposal: Uploading Manifest/Plist

Introduce a feature that allows users to upload their app’s manifest file (AndroidManifest.xml for Android or Info.plist for iOS). The service will parse these files to extract key metadata and auto-populate the onboarding form.

Workflow

1. The user uploads either an AndroidManifest.xml or Info.plist file.
2. The service parses the uploaded file to extract:
   • Bundle Identifier:
     • From manifest:package for Android. ref: docs
     • From CFBundleIdentifier for iOS ref: docs
   • Build Number:
     • From manifest:versionCode for Android. ref: docs
     • From CFBundleVersion for iOS. ref: StackOverflow
3. The extracted fields are automatically pre-filled in the onboarding form.
4. The user completes the remaining fields (name, timezone, description) and submits.

Fetching Additional Metadata

Once the Bundle Identifier is extracted, additional metadata (if needed) can be fetched by querying the respective app stores using this identifier:

• For Play Store: Use the n0madic/google-play-scraper Go library to fetch the required metadata.

• For App Store: This is a bit more involved, there's no library like there is for the Play Store. But we'd have to implement this ourselves based on the ngo275/app-store-client library, which is still being maintained unlike the other libraries mentioned in the original ticket.

---

Would love to hear your thoughts! Please let me know if you have any questions or feedback.

[kolharsam]

Alternative Approach: Search by Developer Name

As an alternative or complementary feature, we could allow users to search for apps by developer name. This would:

• Use the google-play-scraper library to fetch apps by developer name for Android.
• Require building a lightweight scraper for App Store developer pages to fetch iOS apps by developer name (again, using the JS library as inspiration)

While useful, this approach is less reliable than the manifest/plist upload feature due to potential changes in store page structures.

[kitallis]

@kolharsam Thanks for your thoughts. I think uploading the manifest files is interesting, because that has all the important details; but I think it should be a step that's in addition to entering manually. I think entering manually will always exist as an option because if all else fails, that's the simplest, and not externally dependent form of getting your app in.

Some additional background: adding the app itself is a very tiny portion of setting up Tramline for the first time. It's about 5% of the overall onboarding cost. After the app is added, there are a lot of integrations to connect and then configure. After which you have to set up the entire release process before one can make the first release. Which means, the ROI on shipping the best possible experience for adding in app is relatively low. However, I think it's still important for it to be reasonably good, because it's the very first thing to do. So on that line of thinking, and riffing off on your thoughts, I can imagine an experience for adding an app like this:

1. Search your app on the stores
2. Once added, show the basic details, ask the user to either upload a manifest or "enter manually"
3. Skip 1 altogether and jump straight into #2.

This will cover all cases:

1. The user's app is not in the store yet, it's not released even once
2. The user doesn't have access to the manifest file readily at hand
3. The user's app is on the store and has access to the manifest file

The reason to not force the user into any one of the buckets is because this is the first thing that they will do, and so there should be always an "out" lest they get annoyed and leave because they can't punch their app details in.

On searching stores

Some more context on why I wanted a search experience in the first place. It's really not all that objectively valuable, all things considered. But it's useful in its subjective feeling; the first look of Tramline being confident. It's a way to transport users into the stores immediately rather than dragging them along a bunch of CRUD. It's a wow thing mostly. Tramline is generally quite pragmatic, but some things deserve a wow experience, esp the very first thing you do in it.

On the scraping libraries

The Go library is archived, and I have no idea if it works, which is why I linked to the Node.js libraries that are actively maintained. This service will combine the results from both stores as we discussed in the issue and provide a general output. If the Go library still works, I would recommend avoiding it to be used directly, but rather used as an exemplar for store-sweeper instead.

[kolharsam]

Hey @kitallis Thanks for a detailed response.

Thanks again for your feedback. I wanted to clarify a few things and share my thoughts based on your response:

1. My intention with the manifest/plist upload feature was never to replace manual input. It was just poor communication on my part to not include this in my proposal earlier. Instead, it’s meant to complement manual entry by offering users a faster, more accurate alternative where possible.
   Like you had mentioned above, Manual input would always remain as a fallback to ensure users can proceed even if they don’t have access to the manifest/plist file or their app isn’t live on the store yet.

2. While the App Store's endpoint makes it relatively straightforward to fetch app metadata, the Play Store requires building a proper web scraper to parse HTML and extract the necessary values.
   Since I don’t have prior experience building scrapers, implementing a robust solution for the Play Store would take significant time and effort. For a trial project, this feels like a lot to take on.

3. I’ll proceed with implementing the caching and tests as discussed, so that part will be done as requested.

4. Would it make sense to defer the Play Store integration for now and focus on delivering the rest of the functionality? Once we have a stable version, we can revisit adding Play Store support.

5. I still believe the upload feature is worth considering because:

• It requires less effort to implement compared to building scrapers.
• It’s more reliable and future-proof, with minimal maintenance overhead.
• It provides users with a fast, error-free way to onboard their apps by directly extracting key metadata from source files,
• Even as a secondary option, I still believe it adds real value to the overall onboarding experience.

6. Handling generic app names is another challenge—since there are often hundreds of similarly named apps, users might spend more time filtering through search results than simply entering a bundle identifier.

7. Since the endpoint needs inputs like searchTerm, resultCount, country, and lang, users already need to provide a fair amount of detailed information to get meaningful search results.

Looking forward to your thoughts—I’m happy to discuss further or adjust direction as needed :)

[kitallis]

@kolharsam Those are all valid points. Responding inline:

Handling generic app names is another challenge—since there are often hundreds of similarly named apps, users might spend more time filtering through search results than simply entering a bundle identifier.

This is an accurate observation, which is why I think we should also allow filtering through the bundle identifier (along with the name), because they are globally unique and people usually know their bundle identifiers off the top of their heads.

That isn't to say that some eyeball-scanning wouldn't be required by users in the filtered list, it would be. But as I mentioned before, I think the point of this feature is to wow. It's just "cool" for Tramline to be able to find their needle in haystack full of apps directly from the source of truth. Not much else. I concede that it in some scenarios it is in fact counterintuitive. That is also the number one reason why I never built this. I wanted to do this 2 years ago, but manual entry was just so much simpler and efficient, that it was never a big enough bottleneck. This only re-surfaced because we want to really improve the first user experience and wow them on the first screen.

I still believe the upload feature is worth considering because:

Your arguments are convincing, and I think, we should consider building this as a part of our onboarding experience improvements along with manual entry + store search.

While the App Store's endpoint makes it relatively straightforward to fetch app metadata

Ah, I didn't actually look into any of those repositories, it does seem like scraping Play Store is a little complicated and App Store seems to have some JSON RSS feed type internal URL. I think we can just tackle App Store for now. That works.

For a trial project, this feels like a lot to take on.

To add to your pint, depending on your appetite, please take a pause before you implement caching even. I think the foremost thing is just to search through the App Store results, and get details and expose an endpoint. That's goal number 1. The rest we can punt for now.

---

Thanks for thinking through the problem deeply and honestly figuring out what you can and can't do. Appreciate this a lot.