After digging in farbic docs alot and exploring multiple stack overflow questions I don't see any information on how to setup Fabric crashlytics for dev(beta) and production both.
Basically I want beta build to log events on separate Fabric app and production build to log on different Fabric app.
Currently Fabric puts its api key in manifest which I think can be controlled for multiple environments but they put secret key in app->fabric.properties file which I don't see can be overridden for different environments.
Any help will be appreciated if someone has achieved this.
Thanks for reaching out. Fabric lets you separate by bundle ID or package name OR API key. If you alter either of these between your build types it'll report to a separate dashboard.
Thanks!
Related
We've been trying to implement a multi environment solution with RNFirebase, but splitting out the firebase projects hasn't seem to done the trick.
We have separated the projects into dev and prod environments, but they both share the same package name/bundle ID, and it seems to have caused issues on our production environment causing people to see a reCaptcha on iOS, that causes a blank screen that the user can't get past.
As for the question, how can we go about separating the environments on the FE side, whilst keeping the bundleID and package names the same(If that is possible)?
What would be the conventional way to write backend code in Expo? For example, have two directories - client and server at the root as below:
ROOT
|-Server
| |_backend files here (ex.Express)
|
|-Client
| |_frontend files here (Expo files)
|
If so, when I publish the project to Expo Go by running the command in the Client directory, how would Expo pick up my backend code in the Server directory?
My goal is to have the project on Expo Go connected to the backend.
Since you're talking about using Express, which is a web server framework, you would basically never distribute this with the client app. It would be deployed separately, and called from the frontend over a network connection.
Having a separate backend, or server, allows you to make it a shared resource. Imagine a shopping app where you had to update the app each time you wanted to see new products - it wouldn't be practical. With a shared backend, you can have a centralized database, or a way to distribute content without updating the app each time, for example. This - commonly called client-server architecture - is the most common pattern in business development today.
This article on client-server architecture might be helpful. https://cio-wiki.org/wiki/Client_Server_Architecture
I am not familiar with Expo. But it sounds like Expo is only taking care of the client/app parts of a full stack application.
In this case I would suggest to have two different repositories, one for the client/app and one for the backend.
My app update has been reviewed, and is now on testing state. I have added internal/external testers like I've seen some threads mention but I still have no option to add the build for publishing to the store. Does anyone know how to move forward?
We have some legacy apps on the Fabric dashboard though not sure if we'd ever needed them again so we could delete them from the dashboard.
If we do republish them, can we undelete them later?
If not, could we get another Fabric key to republish them with?
If you re-onboard the deleted app, by installing one of the kits, and building and running your app, it will re-appear on your Fabric dashboard. The historical data won't be available though. If you recently deleted an app by accident and need to restore the original app and data, we can help you out at support#fabric.io
I read about Worklight's Direct Update feature already. However, I still have some questions that would like to clarify:
Q1: Is it true that Apple allows Worklight Apps to be published to APP
Store even there is a direct update feature?
Q2: How will Apple review and monitor the Worklight Apps' content if
there is a huge change after the direct update? Or, Apple does not
worry about the cached web resource in the application, does it?
Q3: Is there any limitation or pre-condition about the direct update
for the web resource? For example, the major entries of html and js
script files must be existed... etc.
Q1: Is it true that Apple allows Worklight Apps to be published to APP Store even there is a direct update feature?
A1: There are existing Worklight customers that have submitted an application to the App Store and passed Apple's app submission process. For best results, make sure you use Worklight v5.0.6.1 or later.
Q2: How will Apple review and monitor the Worklight Apps' content if there is a huge change after the direct update? Or, Apple does not worry about the cached web resource in the application, does it?
A2: Apple only reviews app submissions to the App Store and whether or not they follow their guidelines. They do not review future updates to the application (as long as it was not re-submitted), for example in the form of a Direct Update unless there are some extra-ordinary circumstances (like inappropriate content that was discovered afterwards, for example...)
Q3: Is there any limitation or pre-condition about the direct update for the web resource? For example, the major entries of html and js script files must be existed... etc.
A3: I am not entirely sure I understand the question. There is no limitation in Direct Update - this feature replaces the existing web resources of an application with new ones. The only thing I can think of is that both the Worklight Studio (that the app was created on) and Worklight Server (that the app lives on) must be of the same version number.
An update.
Apple now allows code updates if you use a webview
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts,
code and interpreters are packaged in the Application and not
downloaded. The only exception to the foregoing is scripts and code
downloaded and run by Apple's built- in WebKit framework, provided
that such scripts and code do not change the primary purpose of the
Application by providing features or functionality that are
inconsistent with the intended and advertised purpose of the
Application as submitted to the App Store.