appcenter-sdk-apple

appcenter-sdk-apple copied to clipboard

I noticed that AppCenter creates a separate folder in Application Support directory on macOS with my app bundle identifier and "com.microsoft.appcenter" directory within it. I prefer to use app name instead and want to keep things clean and tidy. Last time I contacted support this wasn't possible. Can you add this into the roadmap?

Just to stress out, this concerns all nested apps, agents and XPC services that make use of the AppCenter. If a single app contains 5 embedded executables with the AppCenter there will be 5 folders added into the Application Support – a massive-massive mess. Can we have a delegate method to allow specifying custom directory for the AppCenter data? It would fit in organically with the existing architecture! 😌

@ianbytchek Thanks for bring up your concern here. I want to clarify the one that you are concerning about

• do you want to put all files for App Center that are used by 5 embedded executables in one place or
• do you just want to use your own app name for the folder?

The reason why we are using application's bundle identifier as a folder name is that this is a unique value across all the apps but app name could conflict with another app.

I just want to use a custom location for each App Center folder. In this particular case I want it to live under the app-named directory, something along these lines:

Gifox
- AppCenter
  - Main
  - Agent
  - Media

💥 You bring a very good point! Some apps share the bundle identifier, for example the ones using multiple distributions (direct-download, App Store, Setapp) – technically it's the same app, but different builds, or between major versions, like App, App 2, App 3, where different app versions use different data folder, but keep the bundle identifier to keep user defaults under one domain.

This opens the door to major problems – the App Center uses the same location for completely different builds without providing a method of resolving this nicely other than renaming the bundle identifier, which is not always possible without major consequences, for example, App Store-distributed app identifiers are locked and cannot be changed without creating new app profile in the developer account.

Thanks for the reply.

• Can't "Sandbox" be your option? I know, this is a separate thing what you initially talked about but this could fix the issue that you brought up.
• For the naming thing, I don't think "application name" could resolve the issue. I'm sure "application name" has higher chance to have a conflicts than bundle identifier. Making it an optional could be an alternate solution though.
• Putting an app name under "App Center" or "com.microsoft.appcenter" isn't a big deal.

I'll talk about this one with our PM sooner.

I use App Center both with the sandboxed and old school architectures. True, it's way more organic with sandboxed apps, but sandboxing an app is a radical move and not always beneficial.

Just to confirm, I'm not suggesting to move away from the default implementation. It works and you're 💯 right, it's the best option in most cases. I'm suggesting to provide an optional way to provide a custom location to handle cases described above.

Yeah.. Providing an optional way is really straightforward. However we also need to take care of file moves from old place to new place after it changed while App Center is running. There might be other things that should be considered to change the path.

+1 for letting us (optionally) configure the data location. I'm in the same boat as @ianbytchek, already having an application support folder named after my app, not the bundle identifier.

+1 for letting us (optionally) configure the data location. I'm in the same boat as @ianbytchek, but I also need to specify /Library/Application Support/ instead of the home directory version.

We have added this as a feature request.

@hamswan But we're anticipating the feature, not the request… 😄

@jaelim-ms mentioned the data migration challenges. I'm guessing this is the blocker as it puts all the pressure on you guys to figure out how it would work and there doesn't seem to be a straight forward solution. I'd like to add two cents:

1. I can't think of a single reason why one would want to change the App Center data location at runtime – it normally would be configured once in development environment and that's it. Equally, I might decide to change my bundle id, which would create the same implications for the current App Center. There's, of course, a scenario when the a production build gets major changes and the data needs to be moved on users' machines.

2. In which case the app should be solely responsible for data migrations. The delegate method could provide the default data directory url and the app could migrate the data if it needs to and if the data exists. The app would know all earlier data locations if they differ from the default one, so it can handle these cases too. The Crashes could provide the migrate method to be invoked as needed.

// Though, assuming this isn't just for crashes? Perhaps we'd need a separate 
// delegate, like MSServiceDelegate?

public protocol MSCrashesDelegate : NSObjectProtocol {
    // Invoke MSCrashes.migrate(URL, URL) here if needed…
    optional func location(for crashes: MSCrashes, defaultLocation: URL) -> URL
}

open class MSCrashes : MSServiceAbstract {
    open func migrate(fromLocation: URL, toLocation: URL) throws {
        // …
    }
}

As a developer I'd be happy to take the responsibility and to handle migrations myself. This significantly simplifies the feature request and is a win-win for everyone!

+1 for letting us (optionally) configure the data location. Our app has a sub-process which is a console app packaged in the main app. When the app starts, it will start the sub-process. The main app runs in sandbox on MacOS and can find the sandbox path, but the sub-process can not find the sandbox path correctly, so AppCenter cann't write the crash info because of permission issue. Currently, we can not use AppCenter directly for the sub-process because of permission issue. So we just modify the source code and add the api to configure the data location. It is not convenient. We're anticipating this feature.

I have submitted a pull request to plcrashreporter for the api to customize data path, and the pull request has been accepted. Can AppCenter provide an api for customization of data path?

Refer to: https://github.com/microsoft/plcrashreporter/issues/163 https://github.com/microsoft/plcrashreporter/pull/164

Thanks a lot @youbing for you contribution and updating this thread! The PR was reopened and completed here: https://github.com/microsoft/plcrashreporter/pull/167

The changes will be available in the next release.

Hi guys,

Actually, there is no plans to include this feature in the upcoming App Center release. The PR changes will be available in the next PLCrashReporter release though.

I am sorry for the disinformation.

As we do not have plans to add support for this feature in the next year, I'm closing the issue.