* fix(userdefaults): check stored value types in typed getters The typed getters sent NSNumber selectors (integerValue, boolValue, ...) to whatever object was stored, so a persisted value of an unexpected type (e.g. an array or data written from a server response) crashed with an unrecognized selector. stringForKey:, arrayForKey: and dictionaryForKey: returned the stored object unchecked, handing callers the wrong type. Mirror NSUserDefaults: numeric getters accept NSNumber or NSString, stringForKey: converts an NSNumber to its stringValue, and the collection getters return nil for other types. * fix(network): handle non-HTTP responses and nil request URLs URLSession:task:didCompleteWithError: asserted that the task response is an NSHTTPURLResponse. The assertion is compiled out of release builds, so a non-HTTP response (possible when a custom NSURLProtocol intercepts the request) was cast and passed to callers, who then crash calling statusCode or allHeaderFields. Replace the assertion with a runtime check and report a GULErrorCodeNetworkInvalidResponse error instead. Also avoid inserting a nil request URL into the array literal used to log a server trust evaluation error. * fix(logger): look up cached os_log objects by category GULOSLogBasic stored os_log objects under the category key but looked them up by subsystem, so the cache never hit and os_log_create ran for every log message. * docs(changelog): note userdefaults, network and logger fixes * fix(network): keep system errors for non-HTTP responses When a task finished with a non-HTTP response and an error, the error was replaced with GULErrorCodeNetworkInvalidResponse. Pass the more specific system error through and only create an invalid-response error when there is none. Also fall back to the task's original request URL when logging a server trust evaluation error, so the log still names the host if _request is unset.
GoogleUtilities
GoogleUtilities provides a set of utilities for Firebase and other Google SDKs for Apple platform development.
The utilities are not directly supported for non-Google library usage.
Integration Testing
These instructions apply to minor and patch version updates. Major versions need a customized adaptation.
After the CI is green:
- Determine the next version for release by checking the tagged releases. Ensure that the next release version keeps the Swift PM and CocoaPods versions in sync.
- Verify that the releasing version is the latest entry in the CHANGELOG.md, updating it if necessary.
- Update the version in the podspec to match the latest entry in the CHANGELOG.md
- Checkout the
mainbranch and ensure it is up to dategit checkout main git pull - Add the CocoaPods tag (
{version}will be the latest version in the podspec)git tag CocoaPods-{version} git push origin CocoaPods-{version} - Push the podspec to the designated repo
-
If this version of GoogleUtilities is intended to launch before or with the next Firebase release:
Push to SpecsStaging
pod repo push --skip-tests --use-json staging GoogleUtilities.podspecIf the command fails with
Unable to find the 'staging' repo., add the staging repo with:pod repo add staging git@github.com:firebase/SpecsStaging.git -
Otherwise:
Push to SpecsDev
pod repo push --skip-tests --use-json dev GoogleUtilities.podspecIf the command fails with
Unable to find the 'dev' repo., add the dev repo with:pod repo add dev git@github.com:firebase/SpecsDev.git
-
- Run Firebase CI by waiting until next nightly or adding a PR that touches
Gemfile. - On google3, run copybara using the command below. Then, start a global TAP on the generated CL. Deflake as needed.
third_party/firebase/ios/Releases/run_copy_bara.py --directory GoogleUtilities --branch main
Publishing
The release process is as follows:
- Tag and release for Swift PM
- Publish to CocoaPods
- Create GitHub Release
- Perform post release cleanup
Swift Package Manager
By creating and pushing a tag for Swift PM, the newly tagged version will be immediately released for public use. Given this, please verify the intended time of release for Swift PM.
- Add a version tag for Swift PM
git tag {version}
git push origin {version}
Note: Ensure that any inflight PRs that depend on the new GoogleUtilities version are updated to point to the
newly tagged version rather than a checksum.
CocoaPods
-
Publish the newly versioned pod to CocoaPods
It's recommended to point to the
GoogleUtilities.podspecinstagingto make sure the correct spec is being published.pod trunk push ~/.cocoapods/repos/staging/GoogleUtilities/{version}/GoogleUtilities.podspec.jsonNote: In some cases, it may be acceptable to
pod trunk pushwith the--skip-testsflag. Please double check with the maintainers before doing so.The pod push was successful if the above command logs:
🚀 GoogleUtilities ({version}) successfully published. In addition, a new commit that publishes the new version (co-authored by CocoaPodsAtGoogle) should appear in the CocoaPods specs repo. Last, the latest version should be displayed on GoogleUtilities's CocoaPods page.
Create GitHub Release
Update the release template's Tag version and Release title fields with the latest version. In addition, reference the Release Notes in the release's description.
See this release for an example.
Don't forget to perform the post release cleanup!
Post Release Cleanup
Clean up SpecsStaging
pwd=$(pwd)
mkdir -p /tmp/release-cleanup && cd $_
git clone git@github.com:firebase/SpecsStaging.git
cd SpecsStaging/
git rm -rf GoogleUtilities/
git commit -m "Post publish cleanup"
git push origin master
rm -rf /tmp/release-cleanup
cd $pwd
Development
To develop in this repository, ensure that you have at least the following software:
- Xcode 12.0 (or later)
- CocoaPods 1.10.0 (or later)
- CocoaPods generate
For the pod that you want to develop:
pod gen GoogleUtilities.podspec --local-sources=./ --auto-open --platforms=ios
Note: If the CocoaPods cache is out of date, you may need to run
pod repo update before the pod gen command.
Note: Set the --platforms option to macos or tvos to develop/test for
those platforms. Since 10.2, Xcode does not properly handle multi-platform
CocoaPods workspaces.
Development for Catalyst
pod gen GoogleUtilities.podspec --local-sources=./ --auto-open --platforms=ios- Check the Mac box in the App-iOS Build Settings
- Sign the App in the Settings Signing & Capabilities tab
- Click Pods in the Project Manager
- Add Signing to the iOS host app and unit test targets
- Select the Unit-unit scheme
- Run it to build and test
Alternatively disable signing in each target:
- Go to Build Settings tab
- Click
+ - Select
Add User-Defined Setting - Add
CODE_SIGNING_REQUIREDsetting with a value ofNO
Code Formatting
See firebase-ios-sdk's code formatting docs.
Running Unit Tests
Select a scheme and press Command-u to build a component and run its unit tests.
Contributing
See Contributing.
License
The contents of this repository is licensed under the Apache License, version 2.0.