SwiftNativeDeveloper
commented
5 months ago Here are a few other reasons to split the libraries out:
- Only download what you need - For example Package.swift is not needed for Android
- Dependency License management - if the project were open source, had dependencies that had their own licenses, and only using the iOS project, you'd be pulling in a license that doesn't apply to an iOS project that only applies to an Android project
- While one can navigate a directory that is titled 'documentation' it is overhead
- Prevents rock solid top level Readme - APIs have to be different between platform or technology/framework. You can't put integration guide notes at top level readme, which frequently gets previewed in tools like Swift Package Manager within Xcode, among many others.
- Did you know you're on Swift Package Index? https://swiftpackageindex.com/pendo-io/pendo-mobile-sdk This is a good illustration of many of the above
- You're limited from doing platform specific features
Anyways, +1 for splitting the singular library into more than two repos. I.e. iOS Swift should be a different repo from iOS MAUI / React.
Fingers crossed for change in semver SDK version 4.0!
shlomipendo
Platform + Version iOS and Android
SDK Version Any
Framework N/A
Describe the bug For teams that use the semantic versioning of libraries to determine change, impact analysis, when to trigger security/privacy/bug reviews, and finally make a decision to upgrade or not, having a single combined library causes extra work on the teams consuming this SDK.
The entire repository is being tagged the repository contains both iOS and Android libraries. This means, when the repository updates and is tagged for an iOS only change, namely, 3.1.2, 3.1.3, 3.1.4, 3.1.5, you're stating that there was changes to the library. If I'm an Android project, this is noise to our software supply chain and the activities we perform when you declare there is a change.
https://developers.pendo.io/category/mobile-sdk/
https://semver.org
Your major competitors have all split their iOS and Android SDKs into separate repos
Some reasons why strictly adhering to semver is valuable to teams. This supports splitting your SDK into two.
Compatibility - Semver defines version numbers in a way that communicates compatibility. Major version increments signify incompatible API changes, minor version increments indicate backward-compatible feature additions, and patch version increments represent backward-compatible bug fixes. Since iOS and Android platforms often have distinct APIs and feature sets, changes made to one platform may not be directly compatible with the other. Maintaining separate repositories would allow each platform to follow its own versioning scheme, accurately reflecting compatibility and avoiding confusion for users and developers.
Release Management - Semver principles guide the release process by specifying how version numbers should be incremented based on the nature of changes. Following semver allows users and developers to understand the significance of each release and determine whether an update is necessary. In a combined repository for iOS and Android codebases, it may be difficult to apply semver consistently, especially if changes are platform-specific or if one platform receives updates more frequently than the other. Separate repositories provide a clearer framework for versioning and release management, enabling each platform to maintain its own versioning history and release schedule.
Clear Communication - Semver promotes clear communication of changes between different versions of software. By following semver guidelines, developers can convey the nature and scope of changes effectively through version numbers. When iOS and Android codebases are combined in a single repository, it may be challenging to communicate changes accurately, particularly if version numbers do not reflect platform-specific updates. Separate repositories enhance communication by allowing each platform to have its own versioning scheme, ensuring that users and developers can easily understand the significance of updates for their respective platforms.
To Reproduce Steps to reproduce the behavior: Review the tags in GitHub and compare the release notes seeing which releases apply to which platforms.
Expected behavior A clear and concise description of what you expected to happen.
I expect each GitHub repo to contain an SDK for one platform, or series of compatible platforms.
As an example, iOS is separate from Android. iOS would be allowed to live alongside macOS, visionOS, etc.
Logs If applicable, please add crash logs OR pendo logs (can be turned on with
PendoManager.shared().setDebugMode(true))N/A
Sample Code Code snippet or Sample project
N/A
Additional context Add any other context about the problem here.
Just as an example to compare your SDK to, you know your competitors best and could search for their repositories and what the 'norm' is.
Firebase: https://github.com/firebase/firebase-ios-sdk https://github.com/firebase/firebase-android-sdk