The needs of iOS users (iPhone, iPad) are partly met by the existing web remote and stage view features of the built-in Remote plugin. These are accessed through the device's browser.
The OpenLP Remote app for Android has been hugely popular, before it has even reached v0.5. An OpenLP Remote app for iPhone would no doubt also have many potential users. It would also add to the completeness of OpenLP, as compared to commercial offerings (which tend to offer an iPhone app before they get around to Android).
Of course, there a few issues that stand in the road to any iOS development.
iOS development occurs in Apple's own IDE, Xcode, which is only available for the Mac. Not many of our developers own or have access to a Mac. For OpenLP iOS development to begin, and continue, we need at least one developer who has a Mac, an iOS device (for testing), is keen to develop the app, and has the technical skills to learn Objective-C.
OpenLP and the OpenLP Remote for Android are licensed under GPLv2.
iOS App Store
App Store ToS are incompatible with the GPL. Other FOSS licenses may be OK.
- VLC pulled from App Store
- OSS licenses compatible with App Store?
- Open Source, the GPL, and the App Store
- BSD compatible?
If the OpenLP Remote plugin has a public API (which I believe the Android app interfaces with), then anyone can develop a separate closed source or permissive license app, and release that on the App Store.
There are advantages to having a project-affliated/driven app. And given we already have an Android app, it would make sense to pair the development of the Android and iPhone apps:
- Better user experience, if users switch between the two platforms, or if both platforms are in use in the same church.
- Easier support. The closer the apps' UI and features, the less disparate support queries.
- Faster development. Although different platforms and languages, sharing ideas and code would aid development of both branches.
Releasing the iOS app under a different license is perfectly legal, as
long as it does not share any code with any GPL-licensed code. Since iOS
apps are written in Objective-C, the scenario of shared code would be
However, pairing the two that closely would surely
make the iOS app a derivative work or modification. Even if the iOS
developer was merely to browse the Android code for ideas and structure,
that could be seen as a derivative work. Any such relationship falls
foul of the GPL, as it requires all derivative works to also be released
under the GPL (which is incompatible with the App Store).
The solution then would be some sort of dual-licensing, where all the copyright holders of each app agree to share their code with each other, with the understanding that each app will only be distributed under its respective license (whether GPL and closed, or GPL and X11, etc).