In this episode of the AppleVis Extra, David Nason is joined by blind software developer Yannick Plassiard for a fascinating conversation about accessibility, software development, and what happens when the person building an accessible app is also someone who relies on accessibility every day. Yannick is the developer behind App-Suite, a growing collection of accessibility-focused applications that includes aGram, aScan, aCapture, and other projects spanning MacOS, iOS, Windows, and Android.
Yannick takes us back to his earliest experiences with computers, learning to program on MS-DOS and working primarily with Braille at a time when screen readers and assistive technology looked very different from what we use today. From there, he discusses a career that has taken him through accessibility, Braille technology, healthcare, financial systems, and backend development. That varied background has given him an interesting perspective on accessible software design: techniques developed to solve problems in one industry can often prove surprisingly valuable when applied somewhere else.
The conversation then turns to App-Suite and the accessibility problems that inspired Yannick to start building his own applications. We hear about aScan, his approach to making document scanning and understanding easier for blind users; aCapture, which grew from his frustration with the complexity of recording and streaming audio on the Mac; and aGram, an alternative Telegram client designed with accessibility firmly in mind. Yannick also shares some of the lessons learned while developing aGram, including why newer technology isn't necessarily the best technology for every job and how performance problems led him to reconsider an initially SwiftUI-heavy approach.
One of the most intriguing parts of the discussion concerns Talk Forward, Yannick's Android screen reader project. Built from the open-source foundations of TalkBack, Talk Forward explores what an Android screen reader might feel like if some of the interaction techniques familiar to VoiceOver users were brought across to Google's platform. Yannick discusses adding concepts such as rotor-style navigation, improving responsiveness, experimenting with AI-powered dictation and image descriptions, and even developing a custom keyboard in an effort to make typing more predictable and efficient. For anyone who has considered trying Android but found the transition from VoiceOver difficult, it's an especially interesting glimpse at another approach to accessible mobile interaction.
David and Yannick also explore the rapidly changing relationship between artificial intelligence and software development. Yannick explains how AI tools have changed his workflow, allowing him to spend less time writing routine code and more time reviewing, testing, debugging, and thinking about how an application should actually behave. Just as importantly, he makes the distinction between making an interface technically accessible and making it genuinely pleasant and efficient to use with a screen reader. Whether you're a developer, a VoiceOver user curious about how accessible apps are made, an Android user interested in Talk Forward, or simply someone who enjoys hearing how accessibility challenges can inspire new software, there's plenty in this conversation worth hearing.
Thinking About Giving It a Try?
If Yannick's approach to accessibility sounds appealing, App-Suite is well worth exploring. Rather than being a single product, it is a collection of applications created by a blind developer with screen-reader accessibility as a fundamental part of their design. Current projects include aCapture for accessible audio recording and streaming on macOS, aScan for understanding scanned and digital documents, aGram for accessible Telegram access, and Talk Forward for Android.
For iPhone users, aGram is currently available from the App Store as a paid third-party Telegram client. In the U.S. App Store it costs $4.99, with an optional in-app purchase for multiple-account support, and requires iOS 17 or later. The current App Store listing identifies it as an iPhone-only Social Networking app developed by Yannick Plassiard.
Learn More
- Download aGram from the App Store
- Visit the app-suite Developer Website
- Learn more about aCapture
- Learn more about aScan
Transcript
Disclaimer: This transcript was generated by AI Note Taker – VoicePen, an AI-powered transcription app. It is not edited or formatted, and it may not accurately capture the speakers’ names, voices, or content.
David: Hello there, and thank you for joining me once again on the AppleVis Extra podcast. My name is David Nason, here with another episode from our mini-series of podcasts highlighting blind developers or blind and low-vision developers. Today's episode is a really interesting chat with Yannick Plassiard. I'm sure he'll forgive my poor French pronunciation, who is creator of a suite of apps, including a capture, a gram, a scan, and even a screen reader that is similar to how voiceover works, but on Android. So a really interesting chat about development, about his background, about his apps. So really enjoyed the chat with Yannick, and here it is for you now. Let's jump in. Yannick, thank you so much for joining me on the podcast today.
Yannick: Thank you. It's really a pleasure to be here.
David: All the way from beautiful France. Yeah, I believe. How's the weather in France at the moment? Are you in the European heatwaves?
Yannick: I'm in the countryside and in northwest Normandy, which is luckily not very related to heat waves, etc. So we have, of course, it's summer, but the temperature is great. We have kind of good weather with 22 degrees Celsius, something like that. So I won't complain. It's a great place.
David: It's a beautiful country, yeah. So yeah, thanks for taking the time out to talk to us. You're the developer who's popped up on my radar probably in the past year on AppleBiz.com with a number of apps, a whole suite of apps. So we'll come to those. But before we get into the range of apps you've created and that you were working on at the moment, do you want to tell us a bit about your background as How did you get into coding? David Nason, 02:16asking that even?
Yannick: Sure, sure, sure. So I'm blind. I'm 44 years old. So I'm not too young, I would say, but not too old as well. And, yeah, I started coding very, I would say, early days when I was, I guess... 11 or 12 or something like that, because at that time I was working on MS-DOS, if you know that, it's a very old system, a common line system, a common line interface, with very few applications, no internet of course, and well, on this system I discovered So as I said just a little before, no internet. And I discovered that there was a help command in that system. And this help command contained everything the system has to offer, not in terms of usage, but also in terms of programming, which was great because for the first time, as a blind person, I was able to access this information and I was able to study and to learn and to make some progress and read the book. like a physical one. But with this command, that's how I started. And then... Sorry, there was a basic kind of screen reader on this? Yeah, there was a basic screen reader. At this time, there was speech support, but you required to have a dedicated hardware for that. So it was a kind of PCI card or, well, it was not PCI at this time. It was like ISI or even on a parallel port or whatever. And there was a screen reader would send to a dedicated device something to speak and you have a very robotic voice that would speak this to you. But to be honest, I was not using speech. I was more using a more braille user. Because I'm born blind, so I learned Braille when other people would learn how to read and write, I would say, regularly. I learned it in the Braille way. So I was lucky enough to have a Braille device very soon in the early 90s. And so I used that with a dedicated Braille screen reader, which was not that bad and far more simple than our screen readers nowadays just because we have only 80 columns and 25 rows and that's it. So when you think about that, it's really easy to create a screen reader, I would say.
David: We're exactly the same age and my earliest memories of code even being a thing it was basic actually on probably Commodore machines but I never really got into it.
Yannick: Excellent and yeah if we would like to make a comparison for more recent screen readers I would say that this old screen readers now, I would say, resembles to BRLTTY, who Braille users may be familiar with, especially if they're using Linux, Windows, or even the Mac, because we can use BRLTTY on the Mac. I should make a post about this on AppleViz, the way I didn't, but still, I digressed a little bit. uh sorry but then i continued my regular i would say school years and then i graduated and then i went to a computer science school uh with uh which was done in five years i would say which delivered me uh kind of engineer grade or some of master grade something like that and master science and then I started to work in many areas because now it's been like 20 years so I did a lot of things and mainly I work on accessibility on braille device manufacturers and I also worked in healthcare science and market finance as well more recently so plenty of experience different experiences which is great because it learns me a lot regarding how we can shape different software and what are the requirements and the bridge you can do when you create for example an accessible software for accessibility. You may be able to bridge it to kind of market finance because in market finance area there is a lot about performance and about having a system which is very reliable or as reliable as possible and that's very interesting because you could say that those areas accessibility and finance are I would say orthogonal there are nothing in common but still regarding software development there are common things you can apply from an area to another, and that's very interesting to try to say, oh, I saw this kind of thing used in healthcare, for example, and I say, hey, would it be possible to apply this to accessibility? And then you come to computer vision, and then you come to seeing AI. And basically, it's not really, I made a kind of big shortcut here, but it's more or less what happens when you think about an LLM, for example, an LLM who is able to recognize some shapes and then some people and then scenes, et cetera. Basically, this kind of started also in health care when we have some images from radiologists, et cetera, would ask, they would be asked years ago to say, okay, I want to see if we can kind of detect bones or detect, I don't know, shapes in the body so that it would be easier for the surgeons or for doctors to diagnose things. So, everything, software development is kind of a big forest or a big field with a lot of merbramifications and things that diverge, but still they kind of merge at some point and you can always take something from elsewhere and get it back and see if it works. So yeah, very interesting.
David: That's really interesting. And we often hear about things that are developed for accessibility then having applications beyond accessibility, things like speech-to-text or text-to-speech, for example. But this is the case almost the other way around. You saw applications of things that could be applied from another area and brought into accessibility as well.
Yannick: Yeah, yeah, precisely, precisely. And so, After all of this, I decided to get back to accessibility, at least for some time, just to see, especially now that I would say the picture has changed a little bit with the arrival of the AIs and LLMs, etc. It's kind of easier to develop things without having to hire like 20 people just to be able to create one product. So of course there are some advantages and disadvantages as for all technologies but it's very interesting to be able to shape things very quickly and because I'm lucky enough to have developed lots of things before that. I can always compare to what would be the right approach to do this and that and fix, I would say, the LLM, not the LLM itself, but fix the code and detect errors maybe earlier. I hope so, not always, but I hope so, so that I won't lose too much time in round trips with LLM, do this, I said do this, I didn't say do that, I said do this, etc., etc., which can be very frustrating sometimes.
David: So you're still very much in charge, you're still very much bringing your expertise to the project, but the LLM is helping you with efficiency, I suppose.
Yannick: Yeah, yeah, that's precisely it. Although I kind of realized that I spent, I guess I'm spending less and less time in pure coding, like pure, like opening the editor and creating a method or a class or a function or whatever to do this and this and that. I prefer to delegate that to the LLM. but I spend more and more time testing and reviewing. So rereading the code, maybe refactoring myself or testing and create some, I would say, complex test scenarios to be sure that most of the bugs would be caught before the release.
David: I'm guessing with your experience, do you have proficiency with quite a few different coding languages and
Yannick: Yeah, so on my early days and up to, I would say recently, I would say I spent most of my time developing in C and C++ because I was mainly developing back-end software and services. So for the audience, a back-end is something that doesn't... I would say surface to the user, it's not shown, you won't see it, but your application will talk to it to do some certain actions. For example, if you click on Amazon to buy something, there will be a backend, and actually much more than once, who will proceed your request and then send back their response to the webpage saying, okay, this item has been placed into your cart, for example. And that was, so I was a very, uh, back-end developer, uh, most of my life until recently. And until, uh, again, until the emergence of the eyes that we go, that helped me a lot to design front end, uh, application and front end code in, I would say something which is usable by, by everyone. It's not fancy at all. And because LLMs are not able to do that, they want create a very fancy UI with a kind of really good representation of everything, etc. But still, it's usable. And you won't have like widgets who overlaps one another, etc. So it's usable. And now, I prefer to, well, I use much more different programming languages, I would say. It depends on what I'm doing. If I'm doing backend development, I'm using Rust, mainly for performance. If I'm using frontend, I tend to use the language, the native language for the target device I'm developing on. Of course, for our main subject here, it would be Swift. And sometimes Objective-C, but it becomes less and less useful nowadays. And of course, for Android, it could be Java or Kotlin, depends. And yeah, and on Windows, it would be like a .NET 9 on 10, whatever. I have a very few Windows software, by the way.
David: Okay. I know this is what you're saying about being a backend developer all that time, because obviously as a an accessibility expert as well. We need more people working in front end who are accessibility experts, I think, don't we? So it's good that you're working on front end as well.
Yannick: Yeah, yeah, yeah, sure. And that was precisely one of the pain points when I was at companies and saying, okay, you develop a great software, but I can't use it because it's not accessible. And I could explain them everything regarding accessibility, but when it comes to explain something to a developer, when you talk about accessibility, it's not a matter of telling him, you have to put, let's say, an area label or whatever on their web pages because the developer in question would use a framework to create that web page. Now there are very few developers that would create their front end, I would say, 100% by hand. It's not the way it works right now. frameworks, you use Flutter, you use React, you use Vue.js, you use whatever, and there are tons of them, and all of those frameworks include some ways to create accessible things, but it's often tied into the framework, so you have to find the correct I would say method or property of things to modify so that your software is accessible and sometimes it takes much time to just figure out what would be what this property would be to be able to do that so it's it was a kind of thing for me because I would have loved to make all the software I worked on very accessible to blind people, but I couldn't because it would have required me to learn all the different front-end SDKs and frameworks, which are way too much to do for a single man, for sure.
David: Yeah. You know better than anyone. Than anyone? I don't know.
Yannick: But yeah, I experienced it for sure.
David: Yeah. I don't know that you know better than anyone the importance then of building accessibility in from the ground. Yeah. You know, when you're on a new project and have the advantage of doing this. And I suppose that's what you've done with your own apps. Yeah, yeah, yeah. I tried to.
David: Shall we talk about some of the apps that you've worked on? I know some of the ones I'm familiar with would be Acast, which is an audio app, Agram. I'm not a Telegram user myself, but I know it's certainly a popular one. iScan, I think it's the other A one, isn't it?
Yannick: Yeah. So basically what happens is that I started a dev studio, which is a self-employed one. I'm alone there, which is called AppSuite. And basically the idea was to create some apps mainly for the Mac at the beginning but it extended a little bit later but creating so accessible apps and creating apps I would that would I would say fill a gap that I identified on macOS, mainly on macOS. For example, when you want to scan a document on macOS, I didn't find an app which is simple to use, yet powerful, and I would say would not require you to open an app, select this, do a right click, and then select this action like you can do in Preview, for example, you can become documents, but the interface is not so easy. So basically, I didn't like reinvent everything on one window there is a software which is called open book which does exactly that you launch the software you press space and that's it your document is being read to you and that's precisely what i wanted to to to create so i started with that a scan and basically the a is A mixture between app, between App Street, which is my studio, and between accessible or accessibility. But maybe there would be some more meanings behind that, but that's just the three. When I found three, I said, okay, sounds good. Let's do that. We have a great year. It works. Let's go. So, yeah, I started with iSCAN, and then I started with Agram. First for the Mac because it was easier to develop and then for iOS. And then I started with, I guess it comes with a Capture which is a kind of audio recording and streaming tool yet again, because there are streaming tools and recording tools on the Mac. But to me, when you simply want to like, you are a podcaster, you want to start a podcast with a guest. You don't have to like open a logic pro or Reaper or whatever to set up your, all your things and make some routes and, and, most of the time having to purchase all the software as well like look back or whatever because you need to capture for a cable using virtual devices or set up virtual devices on macOS etc so basically iCapture was meant is meant to to make things simple on this regarding that and and yeah and I I have some other apps that are being developed for the Mac as well. Currently not from iOS, but who knows, maybe if I find a new idea, it would come to life. But yeah, the latest I'm working on, which is currently not really is Amix, it's the idea of creating a DJing application like Virtual DJ or JPRO or whatever, but 100% accessible.
David: Oh, amazing. And would that look good with your Apple Music and Spotify and things like that?
Yannick: It's a little complex to use such platforms because in their terms, they often forbid you to use their music for mix and for DJs, or you have to purchase a separate license. Currently I'm working with a local library, so you import your own music and you can play with that, but of course at some point I'd like to And I would love to integrate with at least SoundCloud and even maybe Beatport or whatever. So more like dedicated DJing platforms that releases some electronic music and etc. So it's not done. But at least there are some possibilities to do that. Because the DJing is the art of what they offer, they provide Lisa licenses so that you can use, you can connect with the platform and use the music for your sets. So that's... Okay, yeah.
David: And like all these, the AppSuite apps, do they come about from yourself in terms of like, are these things that you just discovered, I need these myself and... For some of them, yes.
Yannick: For iCapture, it was the case. Because I hated... First, I started to try to use OBS. Because everyone, when you want to stream, whatever, on YouTube, Spotify, Facebook, whatever, TikTok, whatever you want to stream on, OBS is like the masterpiece. And on Windows, it works very well. On the Mac, I started to use it. It didn't work. So I tried to script it. It didn't work either. So I said, okay, so because it doesn't work, I have to find something else. I tried paid software, which was, they claimed it to be like very 100% for macOS, et cetera, with all the designs, et cetera, but still it was not very, I won't say powerful, but not very handy to use. So that's why I created iCapture. And for Agram, it was a need when I worked in market finance, because when you work in cryptos, et cetera, everything happens on Telegram. So I needed a software to do that. On Windows there is Unigram, which is great, but the official Telegram client is easier. On Windows there are only web versions, as well as on Mac and on iOS, as you know. It's very difficult to use. You always have to turn on screen recognition to use that. So that's why I created this. And when I started to create it on the Mac, I had tons of people who said to me, hey, create it on iOS. please port it to iOS. We say, okay, but well, it's not so easy. Okay, so tomorrow, no, I said it's not so easy. So it requires lots of time to do that. But it was very fun to do, by the way. And creating messaging apps is great to do because you kind of have to fight with the system to be sure that everything is accessible when you are loading conversations with thousands of messages and be sure that the focus won't be, I would say, too far away from what you expect it to be. So yeah, it was very fun.
David: we've all seen very bad implementations of messaging type apps, and some very good ones. So yeah, it's great. Like I say, I don't use Telegram myself, but I'm familiar with the fact that the native app is awful.
Yannick: Yeah, yeah, yeah. And basically what was very interesting is that, for example, you would say, okay, because I'm a developer, I would go to the Apple website and see, okay, what's the framework? What's the blue language? It's Swift. Okay, let's go. Let's go learn Swift. And then you say, okay, what is the framework to develop applications? And you have a look at the latest WWDC, and it says, okay, let's use SwiftUI because SwiftUI is great. You have multi-platform. You can target iOS, macOS, watchOS, whatever the platform, the Apple platform. You create one app to roll them all, which is great. So that's basically what I did. At first, I created an app, an iGram app, for the Mac and for iOS, which was, I would say, we had 90% of code in common, and everything was SwiftUI-based. And then I started, because I didn't use Telegram a lot, to me, it kind of worked with a few conversations with some people, etc. And then I released that, and it was a nightmare. every powered, I would say, power user, Telegram power user, would complain that it's slow, that it doesn't work, that it doesn't run messages, et cetera, et cetera. And after investigating, and taking a lot of time investigating, I realized that SwiftUI, although it's the most recent framework, and it's the framework which is really which Apple focuses when it talks about framework, it talks about SwiftUI all the time. I realized that SwiftUI was not able to handle this and that every messaging platform that would like WhatsApp, like every messaging platform you can think of was using the old framework app kits or UI kits depending on the U.S. because It was yet harder to develop with because it's non declarative, you have to create everything by hand, et cetera, et cetera, but much powerful. And much powerful and much, I would say, with much more performance by a factor of, I would say, 20 or even more. So it was very interesting to learn that sometimes the most recent framework even when it's endorsed by Apple and supported by Apple and promoted by Apple everywhere is not always the correct answer to the problem you're facing so yeah it was very interesting I'm guessing because it's newer and it just takes time for them to build it up Yeah, it seems, well, it's for my knowledge, but I'm not sure that that's the correct story, but I guess that's because they did not start it from zero to create SwiftUI. They took things for their old framework, which works very well, so AppKit and UIKit, and they merged this into a single one But of course, while merging and while, because they wanted to have a single framework to work all the platforms, they probably had to do some trade-offs at some point to like say, okay, we keep that and we don't skip that because that is used only on Apple TV or whatever. And okay, we want or we will present it to the user in another way. And unfortunately, while they did that, at some point, they introduced some latency issues, some performance issues, and even some UI issues with, for example, apps created with SwiftUI on the Mac. There won't be much difference for VoiceOver users, but for sighted users, you may notice that the I don't know, the toolbars are not rendered exactly in the Mac OS style. It's kind of a fusion between Mac OS and iOS and iPad OS, etc. So it may be even a little confusing for sighted users as well. So yeah, it was very fun to, well, very fun and also very frustrating. Because you don't expect a more recent thing to be worse than an older one. But yeah, it was fun at the end.
David: And by the way, in tech context, that's why a lot of enterprises even run older operating systems for a long time. Because they're just like, you're just a thing of what we know.
Yannick: Yeah, yeah, yeah.
David: Probably. Probably, yes. And you actually have created a screen reader, so hopefully for Android.
Yannick: Yeah, so I have some experience with screen readers. So it's not my first try on this. As I mentioned earlier, I briefly talked about BRTTY, which is a Braille screen reader for Linux, but not only for Linux. It runs on every platform, and I created some Braille drivers for the screen reader, and I also made a few things for NVDA when I was on Windows, etc. And also for the Mac as well, for example, if maybe some voiceover users would be interested in that, if you are a blind user which uses Braille, on macOS, you may be interested that BRTTY now supports macOS much better and is able to seize your device when you start it and free it when you stop the BRTTY program so that you don't even have to kill VoiceOver to have to have braille so for example if you are using the terminal you can open a terminal start the RTTY having a great great great experience within the terminal itself and having still voiceover running for all of the tasks which is great because unfortunately voiceover in the terminal is not that good no at least for braille users it's not it's not well it's usable but To me, it's not really reliable. Like using it every day is kind of a pain to me.
David: Yeah, I wouldn't use Terminal a lot. It is a little bit, and it's for a speech user. I'm certainly aware it's not as easy to use or as powerful for us as it is for a sighted user.
Yannick: Yeah, so I had a little experience for screen readers, and... Because I love to play with old systems, I had an Android device for years, and now that I have a dev studio that 100% of the time is dedicated to that, I said, okay, why are there so few, I would say, blind Android users? There are, but mainly users who started on Android would stay on Android. But users who started on iOS, which is my case, started with the iPhone 3GS, which is, well, pretty old. Switching to Android is possible, of course, and I did it numerous times, but it's not so easy. And I wanted to see if it would be possible to create a screen reader, or I would say extend a screen reader to make it, I would say, more familiar or maybe a little more easy to use and not having to like learn again all the, all I would say the muscle memories to do some gestures, et cetera, et cetera. So that's why the software TalkForward has been created for. So basically is to kind of create an experience in Android that just works and that is more or less not so far from what is done on iOS. The idea is not to clone a voice over for Android, but the idea is more to, we know As blind users, we know that some gestures work and some may be more difficult to do. And let's use that memory to create something that just works correctly for most cases and most users.
David: Yeah, no, you're right. Like I said, it's a clever name, TalkForward.
Yannick: Yeah, I love the joke between TalkBack and TalkForward. But yeah, it was also very fun to do because fortunately Android is much more open than iOS and Google releases in a kind of open source, it's not really a GPIV-free but still there is the code behind TalkBack, so not all the code All the recent features are still not released, of course, because they spent some time developing it, so it's fair for them to kind of retain them for a while. But still, the open-source version of TalkBack is usable and already has some features and is a great base when you want to start to create some screen readers and you want to start to kind of tweak things and add things above what's being currently already implemented.
David: So if talk forward is, it's kind of a fork of talk back.
Yannick: Yeah, that's precisely that. It's a, it's a, it's a fork of talk back, which is less and less of a fork given time because I, um, at the beginning I just added features like adding things, uh, which were not present. For example, the rotor gestures, which were not present in TalkBack. I said, okay, let's do that. Let's add this. It seems not too complex to do. And it was not too complex to do, so I added that. But then I added some AI-based features. Like, for example, dictation. Android dictation is more or less like Apple dictation, which is good, but not always 100% accurate, especially when you compare it to an L11, to what can, I would say, modern dictation software can provide with Gemini or whatever. So I added that. And then I said, okay, we have a new Gemini interface, so why couldn't we use it for something else? Let's say, for example, to describe images, which is precisely what Apple does in the 27 series of software that was released this fall. So I said, okay, it could be good to have a kind of image description and even... scene description for example without leaving a screen reader you just do a gesture and it describes what's in front of your camera or it reads do the quick ocr like like seeing ai does for example when you want to read a quick test on a quick text on um i don't know whatever package or or you have or or piece of paper or whatever so it's kind of doing that and then I addressed, well I tried to address and it's still being addressed some performance issues because when you go from voiceover to talkback the first thing you may notice is that it's slow very slow when you swipe your finger and then the time between you swipe your finger and you hear the spoken feedback it's it's very, very slow.
David: So yeah, it tricks. And it particularly noted, I noticed this when I tried Android, especially when typing on the onscreen keyboard, it was painful. Like that was anything that drove me back to iOS. I'd say.
Yannick: Yeah. Yeah. Yeah. You're right. And it's, it's very disturbing when you, you, you kind of, um, um, put a finger on the screen, it saves you on the letter. you lift your finger and it inserts another one just because your finger moved a little bit like for, I would say, 200 millimeters or whatever. And yeah, that's very pain. So that's why. But circling back to that precisely, I worked on performance, just basic, I would say, screen reader performance. And then I said, okay, what's this keyboard issue? and it happened that at first it was very difficult to switch between Braille and on-screen Braille and on-screen letters keyboard so I first did that and then I said okay but Gboard with my screen reader is not so fast or it still has some issues For example, I can't double tap a letter to activate it or keep my finger on the screen and tap with another finger to type a letter. So I said, okay, let's create my own keyboard. And that's a good thing on Android. You can nearly replace any or most of system components with your own. So that's great because... This way, I guess, maybe I'm wrong, but this way you can create a kind of very tailored experience and a kind of experience that just works and of course you won't have maybe all the features the keyboard has just because you won't have 100 people developing tons of themes, tons of predictions, and the work gestures, etc. But for most use cases, it's, I would say, way enough to have something that just works and is reliable and that you can use every day, even on the go or even when you are moving with your phone and typing on the braille keyboard at the same time with a Bluetooth headset. So, the worst conditions ever, it should still work.
David: Yeah, that's cool. No, it's a really interesting project, really is. So yeah, be curious to keep an eye on it. I don't have an Android device myself at this moment, but if I ever have one again, I'll definitely want to try it out. I'm sure, I know there's always people interested in kind of looking at what's going on on the other side as well, however dedicated they are to iOS. Some people are always curious to see what's going on on Android. So to see this is, yeah, it's really cool.
Yannick: Yeah, it's cool because we have different, to be honest, I won't say there are much differences between OSes now. If you take a recent Android device and a recent iPhone, you will have more or less the same, I won't say the same experience, but the same features. You can do practically the same thing. um but uh what changes is precisely the experience and the way how you do things and uh my main device is still ios i i still have an iphone 15 for here and i won't change it for uh or swap it for an android device right now even with my great screen reader because it's not great now it's not so perfect there are still issues there are still things I want to tackle before I would say, okay, now it's kind of good enough to be able to switch 100% on Android. And yeah, but on the other side of the coin, if you want to have other TTSs than the one provided on iOS, Android is your choice here, because on Android you have practically every TTS manufacturer or provider that would create a tiny app to expose the TTS voices to the system. And unfortunately, it's not done on iOS. I try to work on this. but it's really, it takes a lot of time because there is lots of negotiations with precisely with TTS providers. And talk to them and say, okay, I want to be able to distribute your voices in iOS. And they said, okay, but it would cause this and this and that. And you have to sign things and you have to ensure that users can do this with my voice, but not that, et cetera, et cetera. So it's not so easy. And I heard and I read on Apple this, there is a TTS, or there are, I would say, several TTS reads. It spreads saying, hey, we lack a Capella TTS. We lack, I don't know, some other provider, TTS providers on iOS or on the Mac. But if it's not done, be sure that there is a reason why it's not done. And be sure that some of us, of developers here, are working on it. But it's not simple. It's not that simple. It's not that simple as integrating an SDK and let's go. If it was that, it would have been already shit for years now.
David: Yeah, like I do, I absolutely love my iPhone and it works so well and it's very easy to use, but definitely the strength of Android definitely is that flexibility is there. It's just a bit harder to get outside of the standard defaults on iOS, I guess.
Yannick: Yeah, and there is also, of course, the ecosystem. When you have a Mac, an iPhone, AirPods, an Apple Watch maybe, an Apple TV, It's the, all the devices work so seamlessly together that when you bring an Android device into it, suddenly things you forgot for years just pop up and say, Hey, you want to copy and paste? And then just send an email to yourself with what you want to copy and paste or copy it on WhatsApp or whatever. So yeah. Yeah.
David: That's true. It's great. You mentioned earlier, actually, I'm always curious when I speak to blind developers around designing UI because you mentioned earlier that LLMs do quite a basic job at that. How do you manage the kind of visual user interface aspect of your apps?
Yannick: What I do is, so mostly I use LLMs because they do a kind of, correct job in designing the UIs. Second, of course, using a sighted people when I can to be sure that things are, I would say, usable. And the next step for me regarding this is to be able to have sufficient income to be able to hire a dedicated person to do that. So not full-time, of course, but kind of a freelance to be able to go all through all of my apps and maybe recreate UI elements or maybe some icons, some assets, because that's precisely it, the assets that lacks when you are designing with LLMs only. But I would say that LLMs are, to me, the most usable things to create such UIs. I tried to use delegated and native tools to do that, like in Xcode there are some tools, so you can UI inspector, you have the accessibility inspector as well, that could help do things and to detect some behaviors and and some misplacements etc but elements are usually faster and usually it's faster to like take a screenshot of of uh i don't know a screen so you you have your screen you have a let's say a gram for us for example you open your chat list and you say okay does my search bar at the top of the screen is always there even if i scroll So you can just scroll and see if VoiceOver reads it, which is a good hint of still being there. But because accessibility is sometimes, I would say, disconnected from the real UI, and you can disconnect it on purpose from the real UI to be able to do and to present things differently that are physically not on the screen at all. Sometimes it's easier to take a screen capture, send it to LLM and see, because the LLM has the code and the screenshots, it can compare very easily to see if your search bar is at the top and it's still visible or not. And it can even compare that the height of the search bar doesn't change even if you scroll down your list or to be sure that it's not overlapped with some other widgets or whatever. So LLM are very good at that because Computer UI is very, very, I would say, basic. All the widgets are always the same. So a rectangle is a rectangle. A rounded rectangle is always a button, et cetera, et cetera. So it's very easy for them to distinguish between a button, a tab, an icon, a list, et cetera.
David: Okay. Are you patriotically using Mistral AI or do you find others or do you use a range of LLMs? Is that the best way to go?
Yannick: Most of the time I'm using Cloud and especially Cloud Code because it's the most capable and the most efficient I would say coding LLM on the market right now. Even if sometimes and OpenAI releases new models saying, oh, we are better, we are better. It's always a matter of months before cloud gets back to the first place. So currently I'm using this. And for screen recognition, Cloud as well is good. So I'm not using, I would say, dedicated ALM, although I know that Mistral AI is wonderful to do that, and I'm creating currently another app which is not really related to accessibility at all, which uses some OCR to OCR some documents, and Mistral is very good. Mistral OCR is one of the best in the world to do that. precisely on when you have like I would say handwriting or maybe your cash receipt or something like that which is not a for paper yeah it's very good to to detect and to and to scan it and to render information so yeah maybe yeah it could be that's something I have to test it could be a faster or even, I would say, more reliable to use it.
David: Yeah, really interesting space, the whole AI involvement in coding. I was speaking to another developer the other day using AI is kind of part of his learning process. That's what it would be if I was to start doing this. You know what I mean? I wouldn't want to just give it to the LLM and just say, make this. I would want to understand it, but it would be, it's going to be a big part of how people learn, I hope, anyway. But to take a positive approach to bytecoding is that it's not just handing the word off to LLMs, but that it's going to help people learn to code.
Yannick: Yeah, yeah, precisely. The thing is that AI and LLM, at least for now, would want never replaces a book or a teacher just because the way they provide you the information you you will never be sure that the information they provide you is for example you say okay i want to learn swifts maybe it will start with a program that says hello world in swifts which is good but uh beyond that when you go to i would say lesson two lesson three whatever the lesson is, but let's say you want to do, I don't know, a view with a property that changes with some observability, etc., etc., they will introduce a concept, but maybe not in the, I would say, most reliable way that the teacher would do, because they won't have the teaching experience. They have the knowledge, they can like if you ask them for a very specific underground thing in a dedicated Apple framework, et cetera, they can provide you that, which is great. But when it comes to having the, I would say, learning skills to help people learn things, I guess we are not there. We are not there yet. However, what is very interesting to learn when you vibe code with AI is not to learn how to code because the AI will know most of the time better than you what to do. Most of the time. Even for me, when I do some Swift UI, or some app kit, UI kit, etc. Well, sometimes I review the code and I ask the LLM to justify what he wrote. To say, okay, you wrote this, why? To me, it should be better doing this and this and that. And the LLM tells me that, no, I'm wrong. It's not the way it's done because Apple says in their documentation that there is one corner case in which the LLM approach is better and that's why it's better to use that. So, LLM is good at coding. However, humans here, we are great at designing and debugging and troubleshooting. And an LLM won't be as good as a human to do that. So when you vibe code something, the interesting process to me, I won't say it's an absolute truth here, but to me the interesting process is to see what's being done by the LLM, given what you asked, and asking yourself, What's the deviation and why it deviated? Why you asked for a red thing and it has been produced in yellow? So why? And so, of course, between red and yellow, there would be no mistake because the LM now knows between red and yellow, but it happens. most of the time when you say, okay, I want to create, let's say, an app to track what I buy in my grocery store, let's say. And because I don't want to write in Braille and take the piece of paper and then remember that I took this and not that, etc. So I want to create my app to do that. But if you say to the LLM, create an accessible grocery store purchase list, let's say, it will do it. But most probably, it won't be exactly how you want it to be. and most probably it won't be this way just because you didn't hint the llm enough so that it can know what the what accessible means to you for example and even if you say it has to be accessible with voiceover LLMs can create very nasty applications that are accessible with VoiceOver, but usability is a nightmare. Just because there is, I don't know, 44 elements before having the correct button to click on. So, yeah, that's why humans have tons of things to learn while creating this kind of development, I would say, or vibe coding, let's say.
David: Yeah, that's interesting anyway. around your app so people are interested in trying out you know a capture a gram a scan or any of the other apps you've created how can they do this and you know what can they purchase them are they subscriptions how does it all work sure um so regarding apps all everything is available by websites which is app
Yannick: app-suite.eu and so every app is in there except Agram for iOS because I didn't create it yet a page for that but I will do and if you want to try Agram you can have a look at it on the App Store and it's available in for every region, something like that, more or less, except in China, but in most of the world it's available right now. And every app has a free trial. Some of them are free, for example, TalkForward for Android is free. Some of them have the free trial, which is basically 14 days that you can try the app, and then I don't really believe in subscriptions model and I don't like that very much so although I provide some subscriptions for basically I scan because it's maybe it cost a little more than a few euros or whatever except this, except iScan, everything is bought once and for all with a single purchase and you can purchase directly from the app, there is a button at the end of the trial period or even before if you want to, there is a dialogue that pops up and guides you to the purchase process. And of course, for Agram, for iOS, it's a paid app as well, but it's much more simple because it's on the App Store, so basically you you buy it like you would buy a regular App Store app, and that's it.
David: Fantastic. People will be delighted to hear, I think, People love to hear of a one-off purchase these days because they're more and more rare, so people will be very happy to hear that.
Yannick: Yeah, to be honest, it's not so easy as a developer because you already have to find new customers to buy your app, to maintain the income flow. So it's not the best economic model, for sure. And that's why most of apps now rely on subscriptions because it's much easier to predict what would be the annual recurring revenue or whatever. But especially for accessibility, I guess that's not the way it should work. I won't pay myself, whatever the price, I won't pay myself like $10, for example, a month just to use a TTS. So if I'm even not convinced myself of this model, why should I import it for somebody else? So yeah, that's why I did that.
David: That's very good. I'm a fan of people adding chip jars into their apps as well, because sometimes there's an app that you've paid for once, but you kind of think, I'm still using it two years later, I actually would like to maybe...
Yannick: Yeah, basically I did that for, there is a kind of thing you can buy on my website, which is just a kind of a tip jar you can support. And at any time, even if you don't have my apps, basically on the website, you can do that as well. But maybe I should be, I should promote it a little bit more.
David: It deserves it for all the hard work. So yeah. Thanks again, Yannick, for joining me. Really enjoyed the chat. And people can check that out, all your apps out at app-suite.eu. So, yeah, thank you, Yannick. And thanks, everybody, for listening.
Yannick: Thank you. Thank you so much. It's been a pleasure to be here. Thank you.