Releases: dropbox/SwiftyDropbox
Releases Β· dropbox/SwiftyDropbox
10.1.0
- Xcode 16 support
- Split completion execution contexts to allow for background thread deserialization.
- Fix background task reconnection route string format
- Remove first party (Dropbox) user agent special casing.
- Update DropboxTransportClient with downloadContentHost
- Add shutdown method to DropboxClient objc wrapper
- Fix locking in requests, os_unfair_lock not to be directly used in Swift
- Fix mapping from model mock inputs to JSON input, error JSON structure, and backwards Xcode compatibility
10.0.7
- Add data usage to Objective-C compatibility layer privacy manifest
- Ensure that test implementation of secure storage access shares and returns token data
10.0.6
- Add privacy manifest data use descriptions
10.0.5
- Adds privacy manifests
- Fixes singleton auth state when using custom transport client
10.0.4
- Adds leading slash to bundle path to ensure bundle initialization. If the previous deployed version of SwiftyDropbox was 10.0.0 or greater, users may be required to reauthorize.
10.0.3
- Fixes a bug where, when a DropboxClient was initialized with a user-specified DropboxTransportClient using short lived tokens, token refresh was never triggered.
- Fixes a bug where when a DropboxClient was initialized with a user-specified DropboxTransportClient, a default DropboxTransportClient was used after delegated auth.
- Removes logic around determining whether to include a default case in Objective-C compatibility wrappers around swift request box types. The logic was flawed and cannot easily be fixed without larger changes.
10.0.2
- Fixes bug in Objective-C compatibility wrapper where api object subtype information was lost.
- Improves portability of stone and stone wrapper script.
10.0.1
- Previously, if a route was app auth, but not exclusively app auth, it was not generated. Now these non-exclusive routes are generated on the app auth client alongside exclusive routes.
- Fixes a retain cycle in the networking stack where a delegate strongly retained its owner.
- Addresses #265 by calling cancellation handler in the other SFSafariViewController dismissal scenario.
- Bumps minimum deployment targets to match Xcode15
10.0.0
Installation:
- CocoaPods: specify version
10
in your Podfile.
use_frameworks!
target 'MyApp' do
pod 'SwiftyDropbox', '~> 10'
end
- Swift Package Manager: use the "Up to next major version" option (or option of your choice) and specify
10.0.0
.
Features of the new version of the SDK:
- The new version of the SDK is fully compatible with Objective-C, allowing seamless integration and interoperability with existing Objective-C codebases.
- The previous dependency on Alamofire has been eliminated in the new version of the SDK, as it now includes native networking capabilities. This means that there are no longer any external dependencies.
- The new version of the SDK introduces support for background sessions, enabling tasks to be performed in the background even when the app is not foregrounded. Additionally, this support extends to an arbitrary number of app extensions.
- The new version of the SDK provides helpful examples of utilizing background session functionality in TestSwiftyDropbox, showcasing a few usage scenarios and showing how to incorporate this feature effectively into third party projects.
- In the previous version of the SDK, serialization errors could lead to app crashes. In the new version of the SDK, serialization errors are now instead propagated to the application calling the SDK, resulting in a more stable and reliable app experience. There is a new case in the
CallError
enum,.serializationError
, available in route completion handlers. - The SDK now supports making api calls using Swift Concurrency async / await.
- Stone now generates SDK code based on Jinja templates. This approach is significantly more maintainable than the previous string concatenation approach.
- Unit test coverage has been significantly increased.
- Integration tests from the previous version of the SDK are still applicable and are used in the new version of the SDK, ensuring that existing integration scenarios can be maintained and validated.
- The new version of the SDK offers an example of integrating with SwiftUI projects, in TestSwiftyDropbox.
- It is now possible to mock API responses in the SDK, facilitating the writing of tests that simulate different API behaviors and scenarios, ultimately enhancing the robustness of their own testing process.
Breaking changes:
- The new version of the SDK no longer supports Carthage as a dependency management option. If you previously relied on Carthage, you will need to migrate to another supported method such as CocoaPods or Swift Package Manager.
- In the new version of the SDK, it is now necessary to specify the final location for file downloads at the start of the load operation, see download style request. This differs from the previous behavior where the location could be deferred until the completion of the download process.
- Due to the removal of Alamofire, public Alamofire types have been removed from the new version of the SDK. The
SessionDelegate
from the previous version of the SDK has been removed without a direct replacement. AlamofireServerTrustManager
in the new version of the SDK does not have a direct replacement. However, you can implement certificate pinning by providing a URL session authentication challenge handler. This allows for custom authentication behaviors while interacting with secure servers. If your workflows relied on these specific features in ways that are no longer implementable, please inform us so that we can better understand and address any potential issues. - In the new version of the SDK, SDK classes can no longer be subclassed. If your usage heavily relied on subclassing SDK classes, please let us know so that we can provide alternative solutions or workarounds if possible.
- Namespace level route objects, e.g.,
var fileProperties: FilePropertiesRoutes
have been changed from snake case to camel case. - Due to the extensive nature of the rewrite and the introduction of new features in the new version of the SDK, when transitioning to the new version of the SDK it is important to perform thorough testing of your codebase. The significant changes and enhancements in the new version of the SDK may introduce subtle behavioral changes or edge cases that were not present in the previous version of the SDK.
10.0.0-beta.3
Installation:
- CocoaPods: specify version
10.0.0-beta.3
in your Podfile.
use_frameworks!
target 'MyApp' do
pod 'SwiftyDropbox', '~> 10.0.0-beta.3'
end
- Swift Package Manager: use the "Up to next major version" option and specify
10.0.0-beta.3
.
Features of the new version of the SDK:
- The new version of the SDK is fully compatible with Objective-C, allowing seamless integration and interoperability with existing Objective-C codebases.
- The previous dependency on Alamofire has been eliminated in the new version of the SDK, as it now includes native networking capabilities. This means that there are no longer any external dependencies.
- The new version of the SDK introduces support for background sessions, enabling tasks to be performed in the background even when the app is not foregrounded. Additionally, this support extends to an arbitrary number of app extensions.
- The new version of the SDK provides helpful examples of utilizing background session functionality in TestSwiftyDropbox, showcasing a few usage scenarios and showing how to incorporate this feature effectively into third party projects.
- In the previous version of the SDK, serialization errors could lead to app crashes. In the new version of the SDK, serialization errors are now instead propagated to the application calling the SDK, resulting in a more stable and reliable app experience. There is a new case in the
CallError
enum,.serializationError
, available in route completion handlers. - Stone now generates SDK code based on Jinja templates. This approach is significantly more maintainable than the previous string concatenation approach.
- Unit test coverage has been significantly increased.
- Integration tests from the previous version of the SDK are still applicable and are used in the new version of the SDK, ensuring that existing integration scenarios can be maintained and validated.
- The new version of the SDK offers an example of integrating with SwiftUI projects, in TestSwiftyDropbox.
- It is now possible to mock API responses in the SDK, facilitating the writing of tests that simulate different API behaviors and scenarios, ultimately enhancing the robustness of their own testing process.
Breaking changes:
- The new version of the SDK no longer supports Carthage as a dependency management option. If you previously relied on Carthage, you will need to migrate to another supported method such as CocoaPods or Swift Package Manager.
- In the new version of the SDK, it is now necessary to specify the final location for file downloads at the start of the load operation, see download style request. This differs from the previous behavior where the location could be deferred until the completion of the download process.
- Due to the removal of Alamofire, public Alamofire types have been removed from the new version of the SDK. The
SessionDelegate
from the previous version of the SDK has been removed without a direct replacement. AlamofireServerTrustManager
in the new version of the SDK does not have a direct replacement. However, you can implement certificate pinning by providing a URL session authentication challenge handler. This allows for custom authentication behaviors while interacting with secure servers. If your workflows relied on these specific features in ways that are no longer implementable, please inform us so that we can better understand and address any potential issues. - In the new version of the SDK, SDK classes can no longer be subclassed. If your usage heavily relied on subclassing SDK classes, please let us know so that we can provide alternative solutions or workarounds if possible.
- Due to the extensive nature of the rewrite and the introduction of new features in the new version of the SDK, when transitioning to the new version of the SDK it is important to perform thorough testing of your codebase. The significant changes and enhancements in the new version of the SDK may introduce subtle behavioral changes or edge cases that were not present in the previous version of the SDK.