Wikimedia Apps/Team/iOS/Maps service

Summary

The Wikipedia iOS app has released an updated beta version which uses Apple maps as its map data source. This is not an easy decision and a previous beta test led to some discussion of whether this is acceptable given the projects' values. In particular, there were concerns around the privacy of our users, and the use of a visual component with a non-free copyright license.

We have decided to again release a beta version of the app using Apple's maps, with the intention of releasing this version publicly in mid June of 2017. Below we explain the reasons for this.

Background

Last year the iOS app team began design and development of an improved "Nearby" feature. This feature receives a lot of positive user feedback, and its expansion 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 was not an easy decision. 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, even though it is outside the content of the encyclopedia, might do. 

After the initial feature implementation was complete, we then spent significant effort again investigating replacing Apple Maps with the Foundation's existing map service. After that effort, it was clear that despite the unease with using visual content provided by the platform, the Foundation's current map service is not feasible for use in Places.

During this time the Foundation's Discovery team was also being re-organized, and the status of maps support of the type needed by native apps, was unclear. With the draft annual plan of 2017, the Foundation is committing to continue development of maps related services and we look forward to working with that team to replace Apple maps as soon as it is viable to do so.

The Present

In version 5.5 of the app we use the built in maps because:

• The Foundations Kartographer service does not serve vector maps with complete styling. This is being worked on, and is the main blocker for replacing Apple Maps. The included screenshots show the Foundation's maps as currently rendered by MapBox in May of 2017.

San Francisco as rendered by the MapBox SDK using the Wikimedia Foundation's vector maps, as of early June 2017. A more complete style would need to be defined, currently only contains land & water.

• While Apple maps are not libre, they are gratis. If we were to use the bitmap maps served by WMF it would add significantly to the costs for the user.^[vague] Bandwidth costs for users in many countries is a major barrier to accessing Wikipedia. OSM derived maps hosted by 3rd parties would require donor money and potentially add complications around privacy and data sharing.
• Apple maps provide high levels of accessibility for the visually impaired. The MapBox does support some accessibility features, but doesn't support the full range of assistive technologies supported by iOS (the accuracy of this statement is questioned).

While the Foundations's draft annual plan commits to future investment in maps, the timeline and level of support for the unique needs of native apps is still unclear. Holding the release of Places until a compatible Foundation hosted maps service is available would mean keeping users from a well liked and strategically important improvement with no release date. Additionally the Maps programs of the WMF have focused on making it easy and awesome to embed maps in articles. Supporting vector map tiles for navigation and browsing by native apps has different performance and feature needs, which are, rightly, secondary to the core goal of giving editors needed tools for using maps in articles.

The Future

Replacing Apple maps will be a high priority goal of the iOS team for future releases. This will progress on several fronts:

• Complete work on vector tile styles for Kartographer vector maps. This effort is underway under the Foundation's Discovery team.
• Work with User:Mxn and the team at MapBox with ensure solid support for Accessibility features. We are meeting with the team from MapBox in June of 2017.
• Support a developer flag in the app's source code to switch between Apple Maps and MapBox+WMF Kartographer implementations so interested volunteers can help us to test and improve the app in this area without needing to reintegrate MapBox.

FAQ and Specific Concerns

Vector maps

• One core issue is the difference between vector and raster maps. 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 significantly better for the end users of mobile apps. In particular vector maps support arbitrary zoom levels without blurring and pixellation, dynamic labels for the visually impaired, and much less data transmission, especially when pan and zooming maps.
• 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 usable in the app as is (see screenshots above).

Privacy

• Wikimedia Foundation's Legal department reviewed this feature before entering beta and is satisfied that it conforms with the Foundation's Privacy Policy. The app's access to the  users’ geolocation to recommend nearby articles, with the users’ explicit consent, is already part of both apps. The new feature merely adds a different way to visually view nearby articles - the user must, as before, still provide explicit consent for the app to access their geolocation. Users can always turn on or off the provision of their geolocation via their iPhone location settings - more information is on this setting is documented by Apple here.
• On the usage of Apple maps, we also looked carefully at the privacy implications of the feature's requests to Apple's map tile servers for display on the app and we are satisfied there are strong privacy safeguards built into the feature's use. First, these map tiles may or may not be near the actual location of the user and the feature doesn’t involve sending Apple the articles you read or anything about your Wikipedia usage. Furthermore, Apple's public documentation and public statements explain how their maps service is engineered to be protective of the end user's privacy. This means the user's identity is anonymized, users are not tracked over time, no map usage profiles is built for users, all requests are transmitted via secure connections, and a random identifier that is reset frequently during maps usage. You can read more about this in the "Maps" section of this Apple document. Overall, Apple's data collection practices are governed by their privacy policy, which a user must agree to in order to use their iPhone. 

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 added an additional link from our Libraries credits view in the app. 
• After a 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.

Using Platform Libraries

• 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 library is 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, but is produced by a for-profit startup. 

Screenshots and Image Reuse

• One concern around reuse is that the license status of screenshots of maps on the Places tab of the app will no longer be freely licensed. 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 unique to maps. For example taking screenshots of articles with Fair Use images also have this issue.

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 MapBox SDK does not have support for dynamic text sizing built-in (though it could be added with additional work by our team) and some types of VoiceOver based map interactions (zoom for example).
• 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 tools and APIs.

Maps on Android and Google Maps

• The current map interface on Android uses the MapBox library in combination with the WMF's raster tiles. This is required on Android as the app runs on devices which do not include the Google services libraries, so no matter what, a third party library is required to fill in the gap. Additionally the Android app's Nearby feature is much more limited than iOS's Places feature. In particular issues of map responsiveness, particularly around motion and zooming, are much more problematic for search and remote browsing stories Places supports.
• 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 or 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.