Aws-sdk-ios: awsconfiguration.json file should have configurable filename

[Dellybro]

To help us solve your problem better, please answer the following list of questions.

• What service are you using?

AWSMobileClient / DynamoDB / authoCore / APIGateway / UserPoolsSignin / AuthUI / S3 / Cognito

• In what version of SDK are you facing the problem?

2.6.6

• Is the issue limited to Simulators / Actual Devices?

No

• Can your problem be resolved if you bump to a higher version of SDK?

No

• Is this problem related to specific iOS version?

No

• How are you consuming the SDK? CocoaPods / Carthage / Prebuilt frameworks?

CocoaPods

• Can you give us steps to reproduce with a minimal, complete, and verifiable example? Please include any specific network conditions that might be required to reproduce the problem.

I believe that the awsconfiguration.json file should be a config variable in the SDK. The current way it's set up doesn't allow me to have a development / production environment based on the different build configurations on the IOS Device

I am unable to copy files into my mainbundle due to lack of permissions from apple, so it is impossible to create my needed awsconfiguration.json, either production or development, on startup using the build values provided to me via iOS env.

If you need help with understanding how to implement something in particular then we suggest that you first look into our developer guide. You can also simplify your process of creating an application by using Mobile Hub.

[rohandubal]

Hello @Dellybro

Thanks for the feedback! I will take this as a feature request to the team to see when we can get this prioritized.

I do see a valid use-case in using different filenames for different stages of backend.

Thanks,
Rohan

[Dellybro]

Yes please let me know, and keep me updated, because at this current moment, I have to release 2 different versions 1. For External beta testing. Than once the external beta testing has came back as a success, i have to reupload another version with our Live awsconfiguration.json file.

This is rather quite cumbersome.

[frankmuellr]

Hello @Dellybro,

I have added this as a feature request in our backlog and have submitted it to the team for prioritization. I do not have specific timeline that I can share at this point. We will let you know, either on this thread, or through a forum announcement when the feature is released in the SDK.

[aspectgfg]

@muellerfr do you have any suggestions for different build environments until then? We'd like to be able to have an awsconfiguration.json and an awsconfiguration-staging.json

[zigfreid5]

Or better yet - not require an awsconfiguration.json and let me define different environment configuration IDs in code so I can provide them dynamically in initialization and manage them the same way I do for other services

[zigfreid5]

@muellerfr Also, why close the thread? If it's on the backlog it should remain open until added to the SDK. It might be beneficial to allow for other input on how it could be implemented. For example, maybe supporting different filenames isn't the best route. I'm deploying three different targets and using preprocessor flags to determine the proper environment. I'd way rather pass in additional parameters to initializers than have multiple awsconfiguration.json files:

private let mobileClient = AWSMobileClient.init(regionType: AWSRegionType, identityPoolId: String, userPoolId: String, userPoolClientSecret: String)

It seems to me that code is more secure than a human-readable json or plist file in the bundle anyway.

If it has to be an awsconfiguration.json file, instead of having more of them, what about supporting multiple configurations for each service? I use the same Cognito user pool for all the environments, but different appsync apis for each. Maybe something like:

{
  "IdentityManager": {
    "Default": {}
  },
  "CredentialsProvider": {
    "CognitoIdentity": {
      "Default": {
        "PoolId": "XX-XXXX-X:XXXXXXXX-XXXX-1234-abcd-1234567890ab",
        "Region": "XX-XXXX-X"
      }
    }
  },
  "CognitoUserPool": {
    "Default": {
      "PoolId": "POOL-ID",
      "AppClientId": "APP-CLIENT-ID",
      "AppClientSecret": "APP-CLIENT-SECRET",
      "Region": "us-east-1"
    }
  },
  "AppSync": {
    "Default": {
      "ApiUrl": "YOUR-GRAPHQL-ENDPOINT",
      "Region": "us-east-1",
      "AuthMode": "IAM"
    },
    "Staging": {
      "ApiUrl": "YOUR-STAGING-GRAPHQL-ENDPOINT",
      "Region": "us-east-1",
      "AuthMode": "IAM"
    },
    "Development": {
      "ApiUrl": "YOUR-DEVELOPMENT-GRAPHQL-ENDPOINT",
      "Region": "us-east-1",
      "AuthMode": "IAM"
    }
  }
}

... would work better?

Then initialization could be something like:

private let mobileClient = AWSMobileClient(environment: String = "Default")

But maybe the best option would be to allow both the awsconfiguration.json and overridable properties? That way you could include the awsconfiguration.json file with either default values or empty strings for each parameter, and let them be overridden by passing in a dictionary of type [String : Any]?

That way I could still use amplify to generate the configuration, but still support multiple environments.

At any rate, please don't close this thread just yet. Let's have a discussion! :)

[Dellybro]

I think that idea is a pretty good one, passing in the environment as a string. @zigfreid5

The environment should contain the cognito pool Id, credentials provider, identity manager and any other values needed. This way for people with setups like mine, who's API isn't the only difference between environments, will be able to change those values as well!

[zigfreid5]

@Dellybro Yeah, for sure. What I intended to say was that the default environment would be used as a fallback so you wouldn’t have to specify every parameter for every environment if they didn’t vary.
At least that’s how it would work in my head. 😁

[frankmuellr]

Reopening the issues until the feature request has been implemented.

[zigfreid5]

@muellerfr Do you have an opinion on how best to implement this? And by "this" I mean variable environment support?

[frankmuellr]

Hi @zigfreid5 and @Dellybro,

for multi-environment support please check out this newly release beta feature for the Amplify CLI.
https://aws-amplify.github.io/docs/cli/multienv?sdk=ios

Note: The use of this newer version (@multienv) might cause existing projects initialized using a previous Amplify CLI version to no longer function when attempting to manage resources in the existing project, or have unexpected side effects. At this time only use this beta version of the CLI to initialize new projects requiring multiple environments and team workflow support as migrations are not yet supported. Migration support for existing Amplify projects is being actively working on.

[zigfreid5]

@muellerfr I'm very grateful to see that there has been a lot of effort put into supporting this! That being said (and I apologize if this isn't the right place to bring this up), overall, I'm not a big fan of Amplify. It seems to fit small localized teams starting new, simple projects very well, but doesn't seem to account for the needs of larger, globalized enterprises. We have pre-existing dev, staging, and production environments, developed and managed by a team in Sweden, and I lead a small team of two other developers (one iOS, one Android), developing a mobile application utilizing Cognito, AppSync, and Pinpoint in the US. I do not have access to the different environments aside from the IDs, Client Secrets, and URLs that I am given to connect to them.

Mid-development the tooling changed to "all-amplify all-the-time", but there are too many things that are still broken and incomplete.

So many of the newer tools have this shining promise that they will make life easier and magical, filled with rainbows and unicorns, but they require a specific workflow to work properly, and if your setup varies from that, you're SOL unless you can find some random blog that has documented the workaround for your exact situation. To be honest, that has been our experience with many other AWS tools as well, making the poor (or complete lack of) documentation our biggest criticism of AWS altogether.

My frustration here is that this is more of the same. "If you fit into the category that we've defined, and your git is set up in this precise way, and you use amplify alongside it just like this..." then this multi-environment method will be great for you. But if you don't, it's not flexible and you can't use it the way you want.

@muellerfr I hope you take this as less of a rant and more of a piece of constructive criticism. I understand not everyone is in the same situation I'm in, and I might even be the only one who feels this way. This solution may even fit "best practices", but I'm disappointed in the lack of flexibility, and I would need to make quite a few project-level and source-control-level changes to make it work.

[kaustavghosh06]

@zigfreid5 We have opened up a GitHub issue to track feedback for the multi-environment & team-workflow support as a part of the Amplify CLI (which we released last night in Beta). Would be really helpful for us to know some specifics, as to how we can improve the overall workflow as a part of the CLI. Looking forward to your feedback!

[frankmuellr]

Hi @zigfreid5,

Thank you for the feedback. I did not mean to imply that the new multi-environment support in the Amplify CLI solved exactly your use case, and I should have been more clear when I asked you to take a look at the feature. The specific functionality you are asking for currently does not exist in the SDKs, which is why we took it as a feature request. We will let you know on this thread when the feature is released in the SDK.

[Dellybro]

Hi @muellerfr

Thank you for the explanation, I am excited to see this feature be released and will be happy to test it as soon as it does for the iOS SDK.

Thanks.

[sleepysort]

Hopping on this thread a bit late, but I'm in a similar boat.

It'd be extremely useful to be able to either be able to set the configuration in code, or use environment based configs like @zigfreid5 has outlined in their previous comments. The current workaround that we're using is to have multiple awsconfiguration-<ENV>.json files, then add a build step that will copy and rename the appropriate configuration file prior to compilation based on the build configuration. Yikes.

As cool as Amplify is, we've opted to use other tools for managing our AWS resources (i.e. Serverless), and our experience so far trying to use the JS/iOS/Android SDKs without an Amplify managed backend has been pretty challenging, especially since a large majority of up-to-date documentation for these SDKs point you to the Amplify docs.

[Dellybro]

@muellerfr Any luck on this feature?

[m0s]

@muellerfr the "Multiple environments and team workflows" page that you linked with has somewhat unrealistic assumption about the workflow itself, at least when it comes to mobile client. From my experience there is never a separate dev, test and prod branches as assumed in the workflow that is described on that page.
If I need N test environments I don't really want to have N different builds if my N > 10 let's say.
Another pretty important practical problem is when there is a requirement to change the backend for in-field clients without requiring app update, ie via push notifications.

[mureatencio]

Any news? @muellerfr

[mrublev]

Isn't it something already implemented in the android sdk? (since 2018: Link) It has an option to pass configuration as a string to AWSConfiguration to initialize AWSMobileClient.

[palpatim]

@mrublev We have an in-progress task (#1649) on iOS to support configuring AWSMobileClient via in-memory object.

[palpatim]

We released the ability to configure AWSMobileClient via object in 2.11.0. Please let us know if you have any issues with this.

[stale[bot]]

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.