I am wondering how to distribute 2 apps one made with a native implementation and another with a hybrid one.
I can have the same name for them from what I can see, but I think I will have issues at the bundle id.
I want a group of testers to receive the iOS one and the others the hybrid one and I don't want them to know which is which.
(I am interested only for iOS currently, but input for android is welcomed as well)
This is achievable with a few manual dependencies. Here's what you need to do:
Onboard the native iOS/Android app on crashlytics with your Org's API key and Build Secret.
Use the same bundle id, Fabric API Key and Build secret (basically everything same) in your hybrid app.
Distribute 2 apps, 1 native and 1 hybrid, every time. All distributions will go to the same beta dashboard. It depends on you, how you keep track of which one is which (native or hybrid) since all distributions will look the same on beta dashboard.
Here comes the manual part. Each time you randomly select which testers gets native/hybrid app.
NOTE: This should work for both iOS and Android.
Related
I need to put in-app payments into my app. There are two problem areas at present.
Get the TrivialDrive Example app so I can run it on my phone correctly and recompile and install it easily.
Discover the structure of the TrivialDrive app and pick the parts that are relevant to me.
any help is welcome
Using Android Studio 12.5 and Java
The key feature of testing in-app payments is that, although you need to publish the app in (at least Internal Testing) google Play, you can in fact side-load newer builds directly to your device. So it needs to exist in the Google Play app store but subsequent builds can be tested on your device without uploading it to Play.Google
https://docs.google.com/document/d/1oPHyYYWpcfTyXjideWhicAkd1R1N1OwSsPi1xHILFBM/edit?usp=sharing
This document explains straightforwardly the steps to get to debugging on your phone using logcat.
I've to create a mobile app for my small company (150 users).
They use both Android and IOS device, and the only native feature I need is Notifications Push..
Cause of the notifications, I can't go pwa (ios doesn't support), so I would try react native app.
This app is for private usage, so I can't deploy it via App Store, but I can use the "enterprise program".
The problem is the price.. It Will cost 300$ every year, for only one app ?
I think I can leave the program once upon a time the app is deployed.. But have to subsribe when I'll have to update..
I've see the OTA possibility. Do you think I can deploy and Update via OTA (Codepush)?
Thank you
Have a look at Expo, it might be just you need. Comes with push notifications support out of the box, the pre-release/beta development/distribution experience is just beautiful. One-click update (without any OTA settings, configuration, hassle) of your app's JS bundle, QR code sharing, and lots more.
Also, you can use TestFlight (together with Expo) if you guys don't want to pay for anything, but that app will expire after 90 days (and you'll have to re-submit a build every 90 days).
I created a Project using Google Firebase. In this project I added 6 iOS apps that I want to track and manage under a single Firebase Project. The apps are sports related and I wanted to have all of them share the same project for monitoring and management and possibly sharing data with each other. Initially the apps will use Firebase Authentication, Crashlytics, FireStore and push notifications. Over time more of the Firebase services will be added (i.e. A/B Testing, Remove Config, etc.). One the summer I will be adding 6 Android apps. These have been in development over the last 6 months and all the Firebase features appear to be working fine.
Are there issues or downside to setting up multiple iOS apps under a single project? When I setup the apps under the Firebase console it did not restrict me to a single iOS app per Firebase project nor did it give me any warning. My cause of concern is the Firecast from Google titled “Getting Started with Firebase: https://firebase.google.com/docs/ios/setup . Project setup is discussed at the 1:25 mark talking about multiple apps in the same project and the diagram shows 4 apps in the project. An app can be an iOS, Android or Web app and one possible scenario is to create a single project with 3 apps (iOS, Android, Web) which share login and user data. At the 2:20 mark it states “… there is nothing to be gained by cramming them into the same project besides tears and heartache.” but it doesn’t specify what the “tears and heartache” issues are. I googled around and checked additional documentation and no warnings are given or information on best practices.
I did see a posting on Stack-overflow from a Google engineer regarding deep linking that was supposed to be addressed in Q1 2018 (over a year ago).firebase-dynamic-links-for-multiple-ios-apps-in-project .
The one issue we did run into is that we can’t use Facebook authentication in our app. The authentication is setup at the project level for all the apps. But Facebook requires each individual app to be registered for authentication and does not allow the user to register a group of apps. So this prevents us from using Firebase login, but this is the only issue we’ve encountered. We MAY run into a similar issue with Twitter, Yahoo, or another service if we add them as login options. For now we are just using Google sign in along with email sign up.
Any guidance here would be appreciated as we plan on shipping the apps at the start of summer. If we need to reconfigure the apps so each one is in a different Firebase Project we can do that but it’s additional work and we have not run into any issues during development and QA.
I'm developing a mobile app (using React Native for that matter), and I'd like to have one of the members of my team try it out.
With Android, I can just share the apk with them. Is there something similiar in iOS?
There is a bunch of tools to do this. Test Flight is not the easiest way to share a build because you need to submit it to the app store, it needs to be processed, pass through all the checks before someone can download it.
Whilst you should definitely use Test Flight to deploy official test versions, an internally used tool for alpha and beta versions is quicker and easier.
I would suggest a tool like Fabric Beta (currently owned by Google), which is a free app deployment + analytics tool. you will need to add some code to allow it to work but it is a simple process. It comes with a program to help deploy and you can plug it into most CI software.
You will need to ensure you have the device UUID's of people in your internal team to sign the application for their devices.
Test Flight is what you're looking for.
First though you need to add the UDID of your team member's device to the provisioning profile used to create the .ipa (iOS equivalent of an APK). But after that, just follow the information and tutorial(s) at the provided link.
From the Dropbox API doc:
Use a single app key for each distinct app
If you build multiple apps, use one and exactly one key for each app
you make. This makes it much easier for us to debug issues when they
arise. That said, if you're just building the same app for different
platforms (for example, iOS and Android), you can use the same key.
It sounds like multiple-apps-single-key only makes it harder to debug. Does anyone successfully deploy multiple iOS apps with a single app key?
There are a few different scenarios mentioned in the Dropbox Platform developer guide you're quoting from, and it's a bit unclear which really applies to your question. To enumerate everything:
"multiple different apps (on the same platform)" e.g.:
MyCoolTaskApp for iOS
MyCoolTimerApp for iOS
In this case, you need to register different apps with the Dropbox API, which means using a different key in each (since they are different logical apps). Also, this way, users will see the different app names when they look at their linked apps list in their account.
"same app for different platforms" e.g.:
MyCoolTaskApp for iOS
MyCoolTaskApp for Android
In this case, you shouldn't register multiple apps with the Dropbox API, and you should use the same key in each (since it is the same logical app.)
"multiple versions of the same app (on the same platform)" e.g.:
MyCoolTaskApp for iOS Lite
MyCoolTaskApp for iOS Pro
In this case, you shouldn't register multiple apps with the Dropbox API, but due to a technical detail there would be a problem with trying to use a single app key in both, as noted under Can multiple versions of my app (e.g., free and paid) use the same app folder on iOS or Android? in the Dropbox Developer support FAQ. In this case, you should contact Dropbox Developer support for help with getting this set up correctly.
To answer your question overall though, each of these scenarios above have been successfully deployed by various developers, but you shouldn't deploy multiple different apps with the same key.