Getting Started Docs: https://developer.box.com/guides/mobile/ios/quick-start/
The Box iOS SDK in Objective-C (prior to v3.0.0) has been moved from the main branch to the objective-c-maintenance branch. Going forward, the main branch will contain the iOS SDK in Swift, starting with v3.0.0.
Box iOS SDK
- Requirements
- Installing the SDK
- Getting Started
- Sample Apps
- Release Definitions
- Copyright and License
- iOS 11.0+ / Mac OS X 10.13+ / tvOS 11.0+ / watchOS 4.0+
- Xcode 10.0+
Step 1: Add to your Cartfile
git "https://github.com/box/box-ios-sdk.git" ~> 4.0
Step 2: Update dependencies
$ carthage update --platform iOSIf you are using Xcode 12, you must follow the steps outlined here to install dependecies due to a bug in carthage.
Step 3: Drag the built framework from Carthage/Build/iOS into your project.
For more detailed instructions, please see the official documentation for Carthage.
Step 1: Add to your Podfile
pod 'BoxSDK', '~> 4.0'
Step 2: Install pod by running the following command in the directory with the Podfile
$ pod install
For more detailed instructions, please see the official documentation for Cocoapods.
Step 1: Click on Xcode project file
Step 2: Click on Swift Packages and click on the plus to add a package
Step 3: Enter the following repository url https://github.com/box/box-ios-sdk.git and click next
Step 4: Leave the default settings to get the most recent release and click next to finish importing
The process should look like below:
For detailed instructions, please see the official documentation for SPM.
To get started with the SDK, get a Developer Token from the Configuration page of your app in the Box Developer Console. You can use this token to make test calls for your own Box account.
import BoxSDK
let client = BoxSDK.getClient(token: "YOUR_DEVELOPER_TOKEN")
client.users.getCurrentUser() { result in
switch result {
case let .error(error):
print("Error: \(error)")
case let .success(user):
print("\(user.name) (\(user.login)) is logged in")
}
}The usage docs that show how to make calls to the Box API with the SDK can be found here.
The Jazzy docs that show class, method, variable, etc definitions can be found here.
A sample app using OAuth2 Authentication can be found in the repository here. This app demonstrates how to use the SDK to make calls, and can be run directly by entering your own credentials to log in.
To execute the sample app:
Step 1: Run carthage
$ cd SampleApps/OAuth2SampleApp
$ carthage update --platform iOSStep 2: Open Xcode Project File
$ open OAuth2SampleApp.xcodeprojStep 3: Insert your client ID and client secret
First, find your OAuth2 app's client ID and secret from the Box Developer Console. Then, add these
values to the sample app in the Constants.swift file in the sample app:
static let clientId = "YOUR CLIENT ID GOES HERE"
static let clientSecret = "YOUR CLIENT SECRET GOES HERE"Step 4: Set redirect URL
Using the same client ID from the previous step, set the redirect URL for your application in the
Box Developer Console to boxsdk-<<YOUR CLIENT ID>>://boxsdkoauth2redirect, where <<YOUR CLIENT ID>>
is replaced with your client ID. For example, if your client ID were vvxff7v61xi7gqveejo8jh9d2z9xhox5 the redirect
URL should be boxsdk-vvxff7v61xi7gqveejo8jh9d2z9xhox5://boxsdkoauth2redirect
Step 5: Run the sample app
A sample app using JWT Authentication can be found in the repository here. This app demonstrates how to set up JWT authentication with a remote authorization service, and will not run until you provide the code to retrieve tokens.
To execute the sample app:
Step 1: Run carthage
$ cd SampleApps/JWTSampleApp
$ carthage update --platform iOSStep 2: Open Xcode Project File
$ open JWTSampleApp.xcodeprojStep 3: Insert your client ID and client secret
First, find your OAuth2 app's client ID and secret from the Box Developer Console. Then, add these
values to the sample app in the Constants.swift file in the sample app:
static let clientId = "YOUR CLIENT ID GOES HERE"
static let clientSecret = "YOUR CLIENT SECRET GOES HERE"Step 4: Add code for retrieving access tokens
In the ViewController.swift file in the sample app, edit the
obtainJWTTokenFromExternalSources() method:
func obtainJWTTokenFromExternalSources() -> DelegatedAuthClosure {
return { uniqueID, completion in
#error("Obtain a JWT Token from your own service or a Developer Token for your app in the Box Developer Console at https://app.box.com/developers/console and return it in the completion.")
// The code below is an example implementation of the delegate function
// Please provide your own implementation
// ...
}
}Step 5: Run the sample app
Starting Oct 19th, 2019 the Box Swift SDK for iOS will be available for general use. This implies all Box developers will be able to use the SDK to build native iOS applications on Box. Between now and the next couple of months, we will be making frequent updates to the SDK based on feedback from our customers, and this document aims to set expectations with respect to:
- the various release types you will see over the next few months, what they mean and how to identify them
- support policy for each of the release types
Between now and the next couple of months, the Box Swift SDK for iOS releases will be one of the following types:
The initial releases of the SDK starting Oct 19th will be Release Candidate (RC). This means (1) the core functionality is present and tested, (2) additional functionality from this point on will be considered improvements or enhancements based on customer feedback. RC releases are usually more frequent (every few weeks), followed shortly by a current release. If you plan to use an RC release, we recommend:
- that you don't use it for production workloads (If that is unavoidable, we recommend upgrading to the Current Release version once it's ready.)
- that you create a plan to keep your application on the latest RC release version at all times (since older RC releases are considered "out of support" as soon as a new RC release is released)
Also, RC releases may carry breaking changes from the previous release and we advise developers to test their application adequately with the new RC release before adopting it.
The idea behind releasing RC releases is to rapidly iterate on the SDK (bug fixes, feature tweaks, etc.) to get it to a production-ready state, and typically we don't expect to have the SDK in the RC phase for more than a month.
A RC release
- is Considered Active when released
- transitions to End-of-life when the next release becomes Active
A Current Release is considered more stable that a Release Candidate Release and for that reason we expect less frequent releases of a Current Release. We typically expect to refresh Current Releases approximately every 3 months (could be shorter or longer depending on the criticality of the contents of the release).
A new Current Release will usually carry new functionality, bug fixes and may contain breaking changes. We will call out all breaking changes (if any) in the Release Notes section of every Current Release, and we advise developers to test their application adequately before adopting in for production use.
A Current release is on the leading edge of our SDK development, and is intended for customers who are in active development and want the latest and greatest features. Current releases are not intended for long-term use, and will only receive enough support after the next release becomes available to allow for a smooth transition to the new version.
A Current Release
- is Considered Active when released
- transitions to Maintenance 3 months after it becomes Active, or when the next release becomes Active, whichever is later
- reaches End-of-life 6 months after it becomes Active, or 3 months after the next release becomes Active, whichever is later
A Long-Term Support (LTS) release is one which we plan to guarantee compatibility with for an extended period of time. The public interfaces of the SDK should not be changed in ways that would break customers’ application, and the release should continue to receive at least bug fixes for its entire lifecycle. We expect to refresh Long Term Release version every 18 - 24 months.
For the above reasons, we recommend all developers who do not intend to make frequent updates (~every 6 - 12 months) to their application, only use a Long Term Release version of the SDK.
A Long Term Release
- is considered Active when released
- transitions to Maintenance 1 year after it becomes Active, or when the next release becomes Active, whichever is later
- reaches End-of-life 2 years after it becomes Active, or 1 year after the next LTS release becomes Active, whichever is later
Once a release is considered ready for release, a new version is cut and the release enters the Active phase. However, new features may be added to the SDK, including support for new API endpoints.
After a time, the release is no longer under active development, but customers may still be depending on it. At this time, we consider the release to be in Maintenance phase; generally, only bug fixes will be considered for inclusion in new versions. We may of course opt to include new functionality based on customer demand, but in general customers should expect that the SDK feature set will be mostly frozen for the remainder of its lifecycle.
After a release is no longer being supported by Box, it enters End-of-life (EOL) and no further changes should be expected by customers. Customers must upgrade to a newer release if they want to receive support.
Copyright 2019 Box, Inc. All rights reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.