Wikimedia Apps/Team/iOS/Maps service

Summary
The Wikipedia iOS app has released a beta version (5.4.0 1081) which uses Apple maps as its map data source. This is not an easy decision and has already sparked some discussion of whether this is acceptable given our project's values.

Recommendation
We release the beta including Apple Maps and listen. If we proceed with using Apple Maps in production we should also continue to evaluate and advocate for a viable Apple Maps alternative in future versions.

Background
Last year the iOS app team began design and development of an improved "Nearby" feature. This is part of our strategy to use the apps to improve the browsing and exploration of the encyclopedia in ways that are "mobile friendly". Following the Android app's lead we planned to add a map based interface, and with the Discovery team's help we also planned to add significantly to the geo based search capabilities of the app. After some initial technical feasibility investigation we decided to proceed with initial development using Apple's maps instead of the WMF or OSM maps. However this isn't an easy decision and we recognize the concerns around the libre status of visual content in the apps and potential harm to re-users that including non-free maps might do.

After the initial feature implementation was complete, we then spent significantly more time and effort further investigating the technical realities and tradeoffs of making this feature work with the WMF map's service. After that effort, it seemed clear that despite the unease with using visual content provided by a platform service in the app, the feature was unlikely to be useable, maintainable and of the quality iOS users expect, without either using Apple's maps or planning for significant resourcing of map design and services, with native apps included as stakeholders.

Reasons to release the beta as is, with Apple Maps:

 * After trying several alternatives, the built in maps library provides the best user experience, particularly in terms of responsiveness, readability of the map and overall ease of use for the average user.
 * While Apple maps are not libre, they are free (as in beer). Other alternatives may be more libre but add to the end user costs or would require the Foundation to subscribe to the commercial MapBox service. Apple maps seem likely to have the lowest end user cost, both in terms of initial download size for the app, as well as data costs during usage (though if vector maps could be made to work with MapBox, those could also be lower in cost to the user).
 * Apple maps provide basic accessibility for the visually impaired. Further development of an alternative would also need to meet basic accessibility requirements.
 * The most viable path for supporting an alternative is to create styling for the WMF's vector maps service (a potentially major staff design and community effort) and for the app to incorporate them using the MapBox library (which will have end user costs in terms of data and app size). Other alternatives would have even worse tradeoff in terms of usability, privacy and development cost.
 * The WMF's maps efforts are currently in maintenance mode. Future investment in maps, and particularly prioritizing the unique needs of native app maps consumers is unclear at best. Blocking the roll out of improved apps geolocation capabilities on having a viable WMF maps service meeting our specific app needs keeps a desired and useful feature in limbo and out of users hands.

Reasons to hold this feature until WMF served OSM maps are workable:

 * The maps would be both free and libre!!!
 * The foundation and volunteers would have total control of visual presentation. This would allow us to develop maps that can better emphasize Wikipedia content and look less like transit or navigation maps, if we or the community choose to.
 * Work on a well styled, well supported vector-based maps service would benefit future iterations on the maps in the Android app and potentially future web apps, not to mention 3rd party re-users.

What the path forward would look like if we do not use Apple maps:

 * Define style requirements for WMF vector maps and estimate the cost and timeline for the design work. We expect this effort to be significant.
 * Clarify the roadmap around vector maps support generally. This depends on the next steps for WMF funded maps services generally, and also the priority native app needs would have in future efforts.
 * Hide and "stash" the feature until we have more clarity on the viability of this approach.

Code vs Visuals

 * The app incorporates a lot of closed source Apple libraries. It has to to be functional. This discussion is a bit unique in that the library we're including has a large visual and information content element.
 * This issue is further complicated by the fact that some solutions involve using Apple's MapKit code library with our map servers, but that the most viable path to WMF served maps also would require us to add the MapBox SDK. This is a library equal in size to all our other 3rd party libraries combined, which adds significantly to our download size and adds a major external dependency to the app, without any user or developer benefit. Additionally MapBox is open source and built on OSM data, but is produced by a for-profit startup.

Vector vs. Raster

 * One core quality issue is the choice between vector and raster map data. Vector map data is served as structured data which defines the lines and labels on a map mathematically. Raster map data is served as images. There are a number of reasons that vector maps are better for the end users of mobile apps. In particular vector maps support arbitrary zoom levels without blurring and pixellation, and require much less data to be transmitted (meaning less user cost).
 * The WMF's official maps service's vector maps have some incompatibilities between the default vector format we serve and the styled vectors expected by MapBox. So, although its technically possible to get vector maps from the WMF they are not useable in the app as is.

Privacy

 * When originally published on wiki there were some concerns raised around users locations being sent to Apple and the privacy implications. However, in this case Apple has made significant technical effort and public statements to safeguard user privacy for this service. A randomized ID is used and frequently reset and all requests are made over secure connections.
 * Additionally, the app is subject to the same user opt-in requirements for geolocation access as any other app. We cannot know anything about your location or place you on any map, unless you choose explicitly to grant that permission.

Credits and Licenses

 * The app is currently under the MIT license. This allows us to make API calls to other non-free libraries from our code. This license allows us to make calls to Apple's code libraries, as we already do, to make the app functional, and the use of this particular library service doesn't change that.
 * The credits for Apple maps includes dozens (hundreds?) of copyright claims on the maps, including OSM and its contributors. The map includes a link to those credits at all times, and we plan to add an additional link from our Contributors list in the app.
 * After an initial review of our license with Apple to develop and publish the app, and our end user license, there is no need to amend or change these for this feature.

Screenshots and Image Reuse

 * One concern raised by an active Commons admin and app user is that the ownership status of screenshots from the app will no longer be "creative commons" by default. Basically we may be releasing a product the Commons community would not even allow screenshots of, or whose copyright/attribution status takes several pages to list/explain. Although this issue gets to the heart of the values issue here, this issue alone is not so problematic as to prevent release. This is also somewhat similar to current issues with taking screenshots of fair use images in the app. However it does point to the un-natural fit this kind of platform-provided visual content has in our app and ecosystem.

User Cost

 * As mentioned elsewhere, using the WMF's raster tiles in combination with MapBox would add to both the download size of the app, as well as the data costs for users of the feature. That makes any non-vector based solution or any solution which relies on MapBox a little less free (as in beer) to our users. Again, this is not a "deal breaker", and we sometimes choose to send our users extra data for all kinds of reasons, including our values, but this is a trade-off to consider.

Maintenance Cost

 * Although MapBox is a well maintained and open source library, integrating and updating such a large library adds to the ongoing maintenance cost and quality risks for the app. In general we have been working to reduce the number of external libraries in our app as we see significant performance improvements and reduced development costs for each external dependency we can remove. This moves us in the other direction with no real possibility of removing that dependency in the future.

Accessibility and Usability

 * Apple's tiles have labels which can be read by the VoiceOver screen reader used by the blind to access the Wikipedia app, and also support text size changes for users with low vision (known as Dynamic Type). The WMF's maps and MapBox do not have support for screen reading or text size change, and it is not clear how or if such support could be added.
 * Users on iOS are used to two types of maps: Google maps and Apple maps. Although MapBox powers some important apps and allows for significant visual customization which some apps use, it does so using non-free (as in beer) tools and APIs. Providing a user experience not commensurate with other native apps reduces the general usability and user acceptance of the feature.

Maps on Android and Google Maps

 * The current map interface on Android uses the MapBox library in combination with the WMF's map tiles. This is required on Android as the app runs on devices which do not include the Google services libraries, so a third party library is required to fill in the gap. Additionally the Android app's capabilities with maps are more limited than what has been developed for iOS (this is how we iterate across apps in Reading, taking turns on the improving a shared feature), so issues of map responsiveness, particularly around responsive motion and zooming, are not as problematic.
 * We investigated other potential maps services/providers, but apart from MapBox and Google Maps, there doesn't seem to be any viable native maps libraries+services. Google maps is no more free (libre) than Apple (in fact since Apple uses OSM data it is closer to being "editable" than Google's service). More importantly it adds an additional external dependency, privacy concerns and maintenance cost, without alleviating the core concerns.