I have existing code based on PromiseKit that I am migrating to Swift Concurrency, and in migrating it to use AsyncLocationKit, my actual sequence of events differed from your sample code in the README.md. Because of this, I created an AsyncLocationManager instance inside an async function, it didn't work at all, due to that fact that AsyncLocationManager's initializer creates a CLLocationManager without first switching to the main thread. It took me a long time to figure out what was wrong. Because of this, I would suggest that AsyncLocationKit do one or more of the following:

1. Include text in the main README.md stating that when an instance of AsyncLocationManager is created, that must happen in a thread with an active RunLoop (probably the main thread). Side note on this: a globally initialized AsyncLocationManager doesn't work (I'm guessing because it is initialized before the main thread's RunLoop is created).
2. Include a check inside AsyncLocationManager.init that throws an exception if there isn't an active RunLoop on the current thread. (I don't actually know how to check this, since RunLoop.current will create an inactive RunLoop on the current thread when called on a thread with no RunLoop.)
3. Update the first line of AsyncLocationManager.init to be wrapped in a call to DispatchQueue.main.sync() if it is called from anything other than the main thread. (Note: calling DispatchQueue.main.sync() on the main thread will result in deadlock, so this would need to check Thread.isMainThread.)
4. Add DocC-compatible documentation to the library and make sure the documentation for AsyncLocationManager.init and AsyncLocationManager.init(desiredAccuracy:) states the fact that they must be called from a thread with a RunLoop.

In short, given that AsyncLocationManager is designed to be used from async code, the fact that it must be constructed outside of async code is something that I feel should be either mentioned in the documentation, or corrected to not be the case. I realize that CLLocationManager itself makes it clear in its main class documentation that there must be a RunLoop at the time of initialization. But it is not at all clear (to me, anyway) that the same is also true of AsyncLocationManager, and AsyncLocationManager's very nature of being used with async code makes it much more likely to be created from an async function.

I managed to put in a workaround based on this approach. Looking forward to hearing your thoughts on the solution.

This branch comes off my other branch for PR #25, so if you want to see only the changes for this PR, look at the last commit (a37d735).

Fixes #30

I found your library easy to work with (nice work!), so I went ahead and added support for CLAccuracyAuthorization, and also added CLAuthorizationStatus monitoring. I also built a quick and dirty sample app that uses these new API - Locations

Update: I also added support for getting and monitoring CLLocationManager.locationServicesEnabled()

Update2: I also fixed a bug where requests for always authorization would be ignored if we already have when-in-use authorization. (See: Request Always Authorization After Getting When In Use)

closes #24

Just by importing the library into my app Clip Target in Xcode I get the following error/warning when uploading to TestFlight/AppStore:

ITMS-90842: Invalid SDK usage - App clip 'BuildTarget_AC_Base.app/AppClips/BuildTarget_AppClip.app' uses the SDK selector 'requestAlwaysAuthorization', which is not supported. Ensure your app clip is using supported SDK features.

In the rest of my code I use a "#if APPCLIP" to skip code that reference API that are not allowed in AppClips. Is it possible to solve this in the framework as well?

Discussed in https://github.com/AsyncSwift/AsyncLocationKit/discussions/17

Steps:

1. Starting with a clean app that has never requested location authorizations
2. Request when-in-use authorization
3. Tap "Allow Once"
4. Request always authorization

Expected:

Always authorization request returns

Observed:

Always authorization request never returns, since the underlying call to CLLocationManager.requestAlwaysAuthorization() fails silently.

This one is tricky, as there's no straightforward way to tell the difference between when the uses taps Allow While Using App – which will allow a follow-on call to CLLocationManager.requestAlwaysAuthorization() – and Allow Once – which will not. I'm investigating this approach.

This PR adds support for initialising and updating allowsBackgroundLocationUpdates. It also includes a test for the new code. This code builds on my previous PR by using default parameters in the initialisers.

The convenience initialiser init(desiredAccuracy:) wasn't setting the desiredAccuracy of the wrapped LocationManager. This PR fixes the problem by using default parameters to remove the need for this initialiser.

I started with ElyesDer's WatchOS commit 575745ad2b2e367080fbd81d2c53975f15ce9f9a and updated it to the latest base repository code. I've tested it on a real Series 5 Watch during a 25 minute run and it appears to work fine.

close #23

Could you add support for WatchOS? Currently it is failing to build because of references to regions, beacons and visits that are note available on the Watch.