A thought-provoking exercise is to try to compare smartphone development timelines to those of home PCs, and see just in which ways the timelines diverged, which forces acted upon which aspect of the tech at what points, and how that impacted the alienation people feel when interacting with either of these devices long-term. You\u2019ll see some major trends \u2013 lack of standardization through proprietary technology calling the shots, stifling of innovation both knowingly and unknowingly, and finance-first development as opposed to long-term investments.<\/p>\n
Let\u2019s start with a fun aspect, and that is hackability. It\u2019s not perceived to be a significant driver of change, but I do believe it to be severely decreasing chances of regular people tinkering with their phones to any amount of success. In other words, if you can\u2019t hack it in small ways, you can\u2019t really make it yours.<\/p>\n
Can\u2019t Tinker, Don\u2019t Own<\/p>\n
In order to tinker with your personal computer, you need just that, the computer itself. Generally, you need a whole another computer to hack on your smartphone; sometimes you even need a custom cable, and it\u2019s not rare you can\u2019t do it at all. Phone tinkering is a path you explicitly set out to do, whereas computer-based hacking is something you can do idly.<\/p>\n
There\u2019s good reasons for this, of course \u2013 first, a phone was generally always a \u201csubservient\u201d device not meant or able to be used as a development bench unto itself. Then \u2013 phones started really growing in an age and an environment where proprietary technology reigned supreme, with NDAs and utter secrecy (particularly for GSM modems with their inordinate amount of IP) being an especially prominent fixture in the industries surrounding phones. Even Android\u2019s open-source technology was mostly for manufacturers\u2019 benefit rather than a design advantage for users, as demonstrated by the ever-worsening non-open-source driver situation.<\/p>\n Only a few phones ever bucked these trends, and those that did, developed pretty devoted followings if the hardware was worthwhile. Just look at the Nokia N900 with its hardware capability and alt OS support combo, Pixel phones with their mainline kernel support letting alternative OSes flourish, or old keypad Motorolas with leaked baseband+OS source code. They\u2019re remembered pretty fondly, and it\u2019s because they facilitated hacking, on-device or even off-device.<\/p>\n Hacking starts by probing at a device\u2019s inner workings, deducing how things work, and testing the boundaries, but it doesn\u2019t happen when boundaries are well-protected and hidden away from your eyes. A typical app, even on Android, is surprisingly non-explorable, and unlike with PCs, again, if you want to explore it, you need a whole another device. Does it benefit app developers? For sure. I also have a strong hunch it doesn\u2019t benefit users that we could otherwise see become developers.<\/p>\n Part of it is the need to provide a polished user experience, a respectable standard to have, especially so for producing pocket computers to be used by millions of people at once. However, I\u2019d argue that modern phones are suffocating, and that the lack of transparency is more akin to encasing an already reliable device in epoxy for no reason. A device designed to never ever challenge you, is a device that can\u2019t help you grow, and it\u2019s not really a device you can grow attached to, either.<\/p>\n Of course, complaints are one thing, and actionable suggestions is another.<\/p>\n What Do?<\/p>\n In other words, let people easily program phones to flash the screen every time an SMS from a specific person is received, or start audio recording when the user taps the touchscreen three times as the phone\u2019s locked, or send accelerometer movements into a network socket as fast as the OS can receive them. Then, let them wrap those programs into apps, share apps easily with each other, and, since the trend of fast obsolescence requires regular collectie infusions of cash, transfer them from phone to phone quickly.<\/p>\n By the way, if days of Bluetooth and IrDA transfers evaded you, you missed out. We used to stand next to each other and transfer things from one phone to another, a field previously handled, but nowadays these things are somehow relegated to proprietary technologies like Airdrop. This isn\u2019t a problem for personal computers, in fact, they somehow keep getting better and better at it; just recently, I transferred some movies between two laptops using a Thunderbolt cable during a flight, and somehow, this was one of the few \u201cwow\u201d moments that I\u2019ve had recently with consumer-grade tech.<\/p>\n The idea is pretty simple on its own \u2013 if phones are to be personal computers, they should be very easy to program.<\/p>\n The Doohickey Port<\/p>\n What about a bonus suggestion, for hardware customization? USB-C ports are really cool and powerful, but they\u2019re relatively bespoke, and you only ever get one, to be unplugged every time you need to charge or sync. Plus, even if you have OTG, all that 5V step-up action isn\u2019t great for the battery, and neither are USB hardware\/firmware stacks.<\/p>\n What else? Keeping up with the times, these days, you can manufacture flex PCBs decently quickly, with stiffener at no extra cost, and for dirt cheap, too. On a physical level, phones tend to come with cases, overwhelmingly so. In a way, there\u2019s suddenly plenty of free space on the back of a phone, for those with the eyes to see, and that\u2019s after accounting for the ever-increasing camera bump, too.<\/p>\n My bonus idea to make phones more customizable at low entry level, would be an I2C accessory port. In effect, a latch-less FFC socket with exposed I2C, and some 3.3V at non-negligible power. Of course, protect all lines electrically, current-limit the 3.3V and make its power switchable. With modern tech, you don\u2019t need to compromise waterproofing, either, and you can add a whole bunch of protection to such a port.<\/p>\n From there, you can get GPIOs, you can get PWM, and so much more. You could have a reasonably simple GPIO expansion, but also a fully-fledged board with DACs and ADCs bolted on, or a servo control board, or an extra display of the kind phone designers like to add once in a generation, only to find it never be used by third-party apps as sales numbers never really reach the point of wider adoption. Experimental chording keyboards, touch surfaces, thermal pixel sensors,<\/p>\n Does it feel like you\u2019ve seen that implemented? Of course, this resembles the PinePhone addon scheme, with FPCs wedged between the back cover and a set of pogo pins. Notably though, this kind of standard is about having compatibility between models and even manufacturers. You also shed a lot of Bluetooth cruft generally required when developing accessories for modern phones. It requires a flex PCB, sure, but so do pogopin schemes, and there\u2019s barely any mechanics compared to a pogopin array. Is it more fragile than a pogopin array? Yes, but it\u2019s fragile addon-side, not as much phone-side, whereas pogopin arrays tend to be the opposite.<\/p>\n A Sketch And A Dream<\/p>\n Of course, this also relies on the aforementioned Python interpreter, and a decent exposed I2C API. If the only way to tinker with yours and others\u2019 accessories is through bespoke intransparent apps you need a whole different device to make (or modify, if you\u2019re lucky), the hackability aspect wanes quick. In essence, what I\u2019m proposing is a phone-contained sandbox, not in a security sense, but in an educational sense. Personal computers have been serving as sandboxes for decades now, and yet, phones could never really fulfill such a niche.<\/p>\n I think one of the big problems with modern phones is that a phone is barely ever a sandbox, all for mostly historic reasons. Now, if that\u2019s the case, we should make it one. If it\u2019s a sandbox, then it can be molded to your needs through hacking and tinkering. If it can be molded to your needs, then it belongs to you in a whole different way. Will this happen? Quite unlikely, though, I do feel like making some prototypes. Instead, it\u2019s about highlighting a significant aspect that contributes to tech alienation, and imagining how we could solve it given enough market buy-in.<\/p>\n","protected":false},"excerpt":{"rendered":"Smartphones boggle my mind a whole lot \u2013 they\u2019re pocket computers, with heaps of power to spare, and…\n","protected":false},"author":2,"featured_media":63032,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[49,48,190,61],"class_list":["post-63031","post","type-post","status-publish","format-standard","has-post-thumbnail","category-mobile","tag-ca","tag-canada","tag-mobile","tag-technology"],"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/posts\/63031","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/comments?post=63031"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/posts\/63031\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/media\/63032"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/media?parent=63031"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/categories?post=63031"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/tags?post=63031"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/www.newsbeep.com\/ca\/wp-content\/uploads\/2025\/08\/hadimg_sphone_hack_3.jpg\")
<\/a>A Nokia N900 in hands of a user (by Victorgrigas<\/a>, CC BY-SA 3.0)<\/p>\n![\"\"](\"https:\/\/www.newsbeep.com\/ca\/wp-content\/uploads\/2025\/08\/hadimg_sphone_hack_1.png\")
If I were asked how to fix this, I wouldn\u2019t limit myself to opening filesystems back up to a user\u2019s exploration habits, beyond the way they were open even in early Android days. I think modern phones could use a pre-installed Python interpreter, with a healthy amount of graphics libraries, a decent amount of control over the system, snappy well-configured autocomplete, and a library of example scripts you could edit in place; essentially, an Arduino IDE-like environment.<\/p>\n![\"\"](\"https:\/\/www.newsbeep.com\/ca\/wp-content\/uploads\/2025\/08\/hadimg_sphone_hack_2.png\")
I like I2C. Do you like I2C? I know most of you do. I enjoy I2C a lot, and I like how it\u2019s decently well standardized, to the point things tend to just work. It\u2019s not as great at as many things as USB can be, but it\u2019s also comparably low-frills, you don\u2019t need a software stack or a hefty bespoke board. For the most part, with I2C, you can just send bytes back and forth. It\u2019s a low-bandwidth yet high-impact bus, with a healthy amount of devices you can attach to it. Also, CPUs tend to have plenty of I2C ports to go around, often leaving a good few to spare.<\/p>\n