web apps in the App directory, what do you think?
Hi all. A few months ago, an app was submitted to the iOS App directory. It was a fun game about driving a motorcycle and avoiding obstacles. I then submitted an app which is a utility for learning to see using sensory substitution, seeing with sound. These apps were removed. Why? Because they are web apps. Web apps are apps which run in Safari. They can be games, tools, and everything in between. If you use Gmail, Google Docs, or Facebook on your computer, you use a web app. To give you all an idea of what web apps are like, I'll give the link to one of the apps that were removed. Seeing With sound: web app I could not find the Cyclepath mobile site, so maybe some one else could find it. There are not many web apps that we use, but I think that the ones that are available should be allowed into the iOS app directory. After all, the original intent of Steve Jobs was to allow the iPhone to use web apps only, so that web technologies could grow stronger. Thanks for reading, and I hope you try the web app that I've linked to, along with its training pages, and maybe share some of your own.
Simple answer from me is a big fat “no”.
From my experience, browser-based applications cannot be compared and judged on the same basis as iOS apps, so would need the existing app directory to be restructured as much of the information and ratings currently in place would not be relevant or appropriate.
I also strongly believe that including web apps in a directory which already has a very established identity, structure and purpose would be confusing. For instance, without much restructuring to accommodate web apps, I can imagine lots of comments from people saying that they cannot find the app in the app store.
Also, what would be next? Browser extensions, plugins, web sites themselves?
The accessibility of each of those is important to me, but I don't believe that a directory of iOS apps is the best or most appropriate place to be sharing and discussing them.
For what it's worth, I think that my vote is pretty clear.
I'll start by saying i don't know how logical my idea is, here goes.
Accessibility is so fickle, what one says is fine, someone else says sucks. There's nothing wrong with a web app, for a couple of reasons. First, we all have Safari, unless ther are other browsers out there, i'm not aware of and someone has it installed. So right there, you have a firm foundation to run on. The accessibility is halfway done, meaning that unlike other apps which you may need to worry if something is labeled correctly, how to get around a site, you already have the tools, if youhave used safari before. Ok, I click this link, or i need to edit this form field, before i hit continue. I'm saying you have the building blocks already in place. second, you have a new category to explore for apps. I would not mind, any extennsion, or plugin, that someone used on a mobile phone or iPad that works for them. I do understand the first commenters point, people would look for an app in the app store in their chosen country. Yet, I don't know how well this would work on the mobile web platform, but I'd be interested to know. My last suggestion, I'm genuinely curious how difficult it would be to create another directory. I mean we have apple watch, apple tv, general chat, which I would gladly see gone by the way side as I see it as ridiculous, put the web apps in place. I don't know why things get removed, I don't actually find myself submitting apps, based on past treatment I've received on various topics I've hoped to post. There's my dollar fifty. :p
Yes web apps should be allowed. Right now both safari on mac and iOS are starting to support what are called service workers. These are the foundation for Progressive Web Apps (PWA's for short). Also both Microsoft and Google are moving towards these kinds of apps as well with Microsoft being in the lead right now. Basically what these PWA's are is a web page that once you go to it can be then turned into an app on your phone.
This is just my two-cents and does not represent on behalf of the AppleVis Editorial Team nor for AppleVis. Essentially just my thoughts.
I think this present a totally different aspect than what this site was developed for. The site focus on just what one can find in the Apple AppStore with in the iOS and for the Mac OS.
Essentially you are talking about a new category that people can use to enter various accessibility ratings on a given web site. Where the line get confusing is the fact of how a user knows that a site is not just a standard web site to a so-called web site that is a web app. I completely understand where you are coming from and very much appreciate you developing games that can be run on the web that are accessible. I think this will just confuse people and and we will have more work load on our part to determine what entries are web apps and not just a depository of web site reviews.
As this web app is not a standalone app nor can be found with in an Apple AppStore. It simply can't be treated and entered as an Apple iOS App or an Apple Mac OS app. Which is why a whole new category would have to be not only developed but also will present a can of worms. I don't develop for AppleVis nor do I run AppleVis. So, I can't imagine the work that would need to be done for this to happen as a new category. Most of all I'm just having a hard time being able to justify this for what this site was fundamentally designed for.
Based on those reasons I just can't get behind this. So, I'm afraid I am also a no for the idea.
I don't think AppleVis should allow for web apps to be posted in directories. Here are my concerns:
<ul><li>What exactly is a web app? Would you classify <a href="www.facebook.com">the Facebook desktop site</a> as a web app? What about <a href="m.facebook.com">the Facebook mobile site</a>? Perhaps you would. But what about <a href="en.wikipedia.org">Wikipedia</a>, <a href="www.dropbox.com">Dropbox</a>, <a href="www.amazon.com">Amazon</a>, even <a href="www.applevis.com">AppleVis</a> itself? What exactly constitutes a web app? All of the sites mentioned above allow for users to log in and perform various functions, but where do you draw the line between a website and what can be construed as a web app? We would need to achieve consensus on this, and I suspect it will be difficult.</li>
<li>On what platform would we judge accessibility? The way the mobile and desktop versions of websites are viewed can vary very widely depending on the browser/screen reader combination used to access it. See <a href="en.wikipedia.org">Wikipedia</a> as an example. It varies enormously depending on the site, browser and screen reader used to access the site.</li>
<li>How would you deal with web apps being updated? Some web apps, especially those from Google, update all the time. Features are added and others are altered. Accessibility can change literally from day to day. How would we keep up with this when changes are not always made clear to users?</li></ul>
I know I'm just asking more questions that people need to think about if they want this to be taken seriously. AppleVis is regarded very highly by both blind Apple customers and sighted accessibility experts and assistive technology specialists, so it is absolutely critical for AppleVis to provide accurate information to everyone.
I tried submitting CyclePath a while ago into the iOS app directory, and the entry was removed. I replied to that E-mail but never got a response from anyone in the Applevis staff, perhaps the address wasn't monitored. In any case I'll paste the contents of this message here as the contents are, in my opinion, rellevant, with some additional comments.
The other thing is, this is really going to hurt discoverability. I would imagine that blind iOS users check the app directory first. So, if this were just posted to the forum section or to other gaming centric sites like audiogames.net, many people that may like this game simply won’t know about it, and the market for audio games is already smaller than for normal apps.
A lot of work has gone into making Cyclepath work in iOS. I’m pretty sure that if not for the fact that you enter the game through Safari and you have the navigation buttons at the bottom, you couldn’t tell it’s a website. At the same time, there are tons of apps in the app store that are just wrappers of websites, for example all the “Choice of games”. And those can be found in the iOS app directory. So in my opinion, rich internet applications or complex games that run on top of web technologies should be allowed, especially because they are only going to get more, not less common.
Games in particular will be affected. Like I said in my Email above, the accessible game market is small enough as it is, and over the last few years I met quite a few people who don't have a computer and only use their iPhone and maybe an aging braille note taker for internet access. Applevis is a great site for marketting to people like that, but only if people are allowed to post to the iOS app directory because I wouldn't expect someone with just an iPhone and braille display to check the Mac app directory for games that they can play on their phone, or reading through forum posts, if all they do is look at the front page or follow the RSS feed. Cyclepath is one example of such a game, but as another example, Oriol Gomez is currently porting BeatStar to web technologies. It's a bop it style game with the ability to make your own music and sound packs for it, there's over 300 of them now ranging from various decades, styles and topics. It's a very simple and not violent game which would appeal to a lot of people, not just hard core gamers. But these kind of people also don't follow websites like audiogames.net
Web apps, especially when progressive web apps are introduced, are going to heavily blur the lines between native and web apps. I strongly agree that any form of application designed for mobile use on iOS should be able to stand a chance in the app directory. It's an application like any other. Web apps are already in this directory, things like Amazon, the Alexa app and many more which are built onto of web technologies and only have a renderers the actual app which loads a website that was made with Phonegap/Cordova API's or similar. So to be fair, not only web apps from the App Store bundled with a web view in a Swift app should stand a chance, every app should be able to testify it's usefulness on this site. Web apps are going to be able to do more and more. We have the excellent webaudio API with binaural sound, we have many more like bluetooth, accelerometer, camera, about any sensor in the device and so much more. I don't see the reason against including web apps.
Hi all. @tjt2001, I disagree on your views of web sites versus web apps. You mentioned Amazon, Facebook, and let's add Google to the mix. You also mentioned Dropbox. They all have their native apps, so it would not be clear to classify them as "web apps," as you can either, go to the site, perform the tasks, or use the apps should you so choose. a web app, from my understanding is that it runs, within,t he browser itself. So using a browser, you'd say play a game, or maybe edit that document you should've done 24 hours before you got caught. In other words, it's within another part of the same mobile platform. I also disagree with your definition of screen reader, browser combination. Again if i have this correct, we are talking Safari, and Voice over, or Zoom or if there's other low vision aspects, them as well. We're not talking Windows and their bevy of screen reader choices and them the Mac side, we're talking one standard that will only change, whenever IOS will. Accessibility may change from day to day, however you can say that about anything, any update on any app.
anonymouse, I agree it might be difficult developing a new category, yet if you can already put up categories for the aforementioned Apple watch, Hardware, Apple tv, Braille, hardware etc. So how hard is it then, to put up, safari web apps? I realize you are not talking for Apple vis. I just see us stalling out with developement of this site in general, because there are a lot of places to find an app, that does not rely on the app store. Yet, for convineience sake, you only promote apps in the Mac app store. Again, it's easy for people to find it all in one place so to speak. If we don't branch out, we don't grow as a community, and as a group of well thought educated people. I mean educated only to say, that hey this app from the Mac app store is ok, but here's a better one that is not available from another site. I basically am saying that like windows, we had to go searching for apps that we needed. We can do the same thing just learning new ways. Hope my point made some sense. If it also means we need to find more contributors to the site, that isn't to hard to do.
So essentially in this example you want AppleVis to start providing a category for Mobile Gaming. That is not Apple specific as it will work cross platform and cross browser. The argument in the angle you can take that this can be run on Safari on our iPhone and on the Mac.
As I do understand that this may be the future of mobile development. I don't see this will be replacing various apps mentioned that simply take their wrapper to this technology, so it can be used as a standalone app. Most of all that users will still be able to find easily with in the AppStore. It is simply suicidal on their part currently to remove those AppStore apps to go strictly to a simple web link.
My understanding from the conversation so far is that this is one less thing a developer must do in not having to pay money to make an app exist in the AppStore. Without that item being in the AppStore. This game wouldn't have much of any kind of awareness or chance to be heard and seen if there is not a place to do that. Is that what I understand?
Also, if one were to load this game up from the Safari say from an iPhone. Will that users have total VoiceOver controls? So, will gestures still work as we know as they are on our iPhone? So essentially will anyone even know that it looks, smells, hear like a regular app on our iPhone? I ask because I don't know, and I like to understand.
How can users tell what mobile sites are web apps and which are not so that there isn't any confusion for the users?
If Apple and they will update Safari from time to time. As we get updates and new iOS versions. Will this affect any of these games or mobile web apps? Right now, we ask what version an app that a user post and the iOS version it was tested on. I can say we want to keep the iOS version of what it was tested on and a link to the mobile web app. But, where do users find the descriptions so that an entry can be made easily?
Since this is not specific to Apple and this being an Apple related site. Why would we want to do this and start a new category that will simply be blurred of exactly what this is?
Lastly, how can I trust that any links that we post on AppleVis that it will be safe for our users? Where the AppStore is protected for the most part and have various rules developers have to use.
Just wanted to ask these questions so I can get a better idea of what this is all about. So, thank you for taking the time to answer to my various questions!
I have been following this discussion with great interest, and am glad that I didn't jump in immediately, as listening to the comments of others has resulted in my position moving somewhat from where it started.
As it stands right now, I am convinced that sharing information on the accessibility of web apps clearly has a place on AppleVis - it falls within our scope and would have interest and value to the community.
However, what I will say from the get-go is that I do not believe that allowing web apps to be posted to the existing iOS App Directory is the best or most appropriate thing to do. Essentially, it would be like trying to make that square peg fit in a round hole.
If we are to collect and share information on web apps, it appears that what's available and what's going to be of interest and value to readers is not the same as what we collect and share on iOS apps. As a result, there are practical and efficiency reasons for not trying to make them fit together. As others have also already said, it could also result in a situation which could be confusing to some.
So, my preference would be to create a dedicated area of the site for web apps. This would allow us to create something which allows for their very specific nature; the information that's available; and appropriate ways to assess and compare their accessibility.
Another “however” is that I am still to be fully convinced that now is the time to roll this out, as I am not sure that web apps are at the level of maturity where we can put in place a structure for any “directory” which we can be confident would be appropriate for the future. From past experience, I know how much better it is to have things right from the get-go rather than have to change things later on. We've had to do this with the iOS App Directory as the platform has evolved over time, and it's an experience that I would prefer to avoid in this case if at all possible.
At the very least, it would seem appropriate to at least wait until Apple formalises its plans for web apps in the next major OS releases.
I've never really thought about this but it's interesting. Most of you have probably heard of Easy Chirp, the cross-platform web interface for Twitter. I have used it for several years now, starting on Windows. It works great on Windows and the Mac platform, and the developers are very responsive. I've tried it out in Safari and Google Chrome with Chromevox, and it works in both browsers. I think I'd have to say yes as well to this. If CyclePath and Dark Defender are both listed in the app directories, then I don't see why something like Easy Chirp should be excluded. Granted Easy Chirp is strictly a web interface, but why not list it and others along with everything else? I also just thought of something. I wonder if the goal-tracking portal used by a local nonprofit with which I've been involved should be submitted here? It keeps going busy in Safari, and is only marginally accessible with Chromevox. I think I'd have to talk with the creators of this portal though since they own the rights.