Marco Eidinger (via Dave Verwer):
A nice surprise is that SwiftUI supports GitHub Flavored Markdown (GFM). […] An Apple engineer confirmed the use of GFM in the Apple Developer forum.
[…]
Using a string literal in Text works. Fine, but using a string variable does not! […] The trick is to use init(_:) of LocalizedStringKey.
[…]
You might run into the situation that you have an AttributedString with line breaks (\n), but those line breaks are not displayed.
The trick is to add the .inlineOnlyPreservingWhitespace option when initializing the AttributedString.
GitHub iOS iOS 15 Mac macOS 12 Monterey Markdown Programming Swift Programming Language SwiftUI
Bare Bones Software:
Image files are browseable in disk browsers and projects, and openable into ordinary window sidebars. The image view includes metadata details, and a “Remove Metadata” button is available for deleting image metadata if desired. (BBEdit will create a macOS version snapshot of the image file before doing so, if possible.) BBEdit will attempt to pick a background color (shade of gray) that provides reasonable contrast with the image. If desired you can adjust the background color using the slider adjacent to the image, and BBEdit will remember this setting per-image.
The File Info item (in the navigation bar) and “Get Info” command (from the menu bar or contextual menu) will show an image thumbnail and the image metadata in respective tabs in the info popover.
[…]
“Process Lines Containing” provides the option to invert the match test, such that lines which do not match the provided search string or pattern are collected, rather than those which do.
[…]
BBEdit can load codeless language modules written using YAML or JSON. This may lower the barrier to entry, since (depending on your individual predilections) either is simpler to read (and write) than XML property lists. The keys and values remain as documented.
[…]
For documents in languages for which a language server is installed and running, “Show Symbol Help” on the Edit menu will show detailed information based on the start of the selection range in the document. (This is based on the LSP “hover” feature, for those who are curious.)
Previously:
BBEdit Graphics Mac Mac App macOS 12 Monterey Programming Text Editor
Ken Case:
This multi-platform automation for our apps—called Omni Automation—is now extended by Shortcuts to the rest of the platform’s automation world. Shortcuts on the Mac makes that power more accessible than ever, both to end users and to developers creating the app ecosystem.
In addition to bringing over the OmniFocus Shortcuts actions we already support and ship on iPhone and iPad, we’ve added two new Shortcuts actions to all our apps which integrate with Omni Automation. By including “Omni Automation Script” and “Omni Automation Plug-In” actions with each of Omni’s applications, our robust device-independent application scripting merges with Apple’s updated Shortcuts automation frameworks in the iOS, iPadOS, and macOS operating systems.
Ken Case:
For anyone who uses any of our apps on an iPhone or an iPad, we’re starting out the year with updates across the board. With these updates, Omni Automation in Shortcuts is available across all of our apps and on all platforms.
Previously:
iOS iOS 15 iOS App JavaScript Mac Mac App macOS 12 Monterey OmniFocus OmniOutliner Shortcuts The Omni Group
Anthony Chavez:
Today, we’re announcing a multi-year initiative to build the Privacy Sandbox on Android, with the goal of introducing new, more private advertising solutions. Specifically, these solutions will limit sharing of user data with third parties and operate without cross-app identifiers, including advertising ID. We’re also exploring technologies that reduce the potential for covert data collection, including safer ways for apps to integrate with advertising SDKs.
The Privacy Sandbox on Android builds on our existing efforts on the web, providing a clear path forward to improve user privacy without putting access to free content and services at risk.
We realize that other platforms have taken a different approach to ads privacy, bluntly restricting existing technologies used by developers and advertisers. We believe that — without first providing a privacy-preserving alternative path — such approaches can be ineffective and lead to worse outcomes for user privacy and developer businesses.
Sami Fathi:
Unlike Apple’s ATT, which requires all apps to ask for user consent before tracking them across other apps and websites, however, Google’s Privacy Sandbox will limit app ability as default while also looking for new privacy-preserving ways to enable mobile advertising.
[…]
Google’s approach is striking a different tone, with Snapchat, who had previously said ATT presented a “risk” to its business, saying in a statement that it is “excited to collaborate with Google to develop new privacy-preserving standards for Android.” Google said it would receive input across the industry as it builds Privacy Sandbox over the next two years.
Previously:
Update (2022-03-09): John Gruber:
Two years puts them around three years behind iOS, which implemented App Tracking Transparency (ATT) last year. Or maybe that’s just three years until Android jumps ahead of iOS on privacy guards against surveillance advertising, since ATT is the “blunt”, “ineffective” approach Google is attributing to “other platforms”.
Ron Amadeo (via John Gruber):
That bit about being a sandbox for “compatible SDKs” is the big catch for the SDK Runtime and the Android Privacy Sandbox. It’s optional. Chrome’s Privacy Sandbox, even if it is a watered-down privacy solution, is at least starting with the progress of blocking third-party cookies. The existing tracking methods in Chrome will be blocked, and Google is offering an alternative solution that will have some (again, watered-down) privacy benefits. Google has not announced plans to block or limit any existing tracking techniques on Android. Android apps have a lot more privileges than a website, and developers could choose to ignore this and include an ad SDK that does not use the SDK sandbox.
Nick Heer:
I am finding it hard not to read the details as an overcomplicated way to meet in the middle without clear benefits. Google’s market dominating advertising business means regulators will surely raise concerns if any Android ad tech companies are affected by more meaningful changes, so Google must take a more cautious approach. But that means the result will likely be ineffective for privacy.
Advertising Android App Tracking Transparency Privacy
Steve:
My experiences with Microsoft dev relations over the past decade have been nothing but positive and frictionless. My experiences with Apple have been nothing but combative and “computer says no”
Via Florian Mueller:
As for “computer says no,” the problem is that Apple has to handle such huge quantities of app submissions every day that they have to automate the process to a high degree, and flexibly assign new requests to whoever is available to respond. That makes the experience impersonal most of the time.
[…]
It’s also understandable that Apple says you must submit an actual app to them to get a decision. You can’t just describe what you plan to develop and ask them whether they will approve. Here, again, the problem is not that they do it that way: the problem is that if you actually create that app and they reject it, it’s one click for them (plus another to reject your appeal) and an enormous loss for you as a developer.
Tim Carr:
That feeling every time you hit the “Submit for Review” button knowing that a single reviewer at Apple might decide your entire app was never ok and torpedoes it off the App Store - it is unique, never had that horrid fear anywhere else.
Tim Carr:
I still remember being halfway thru a long drive to a week’s vacation & having to stop in a random timmyho’s summer-hot parking lot in order to plead with an App Reviewer who actually called me, for the life of my app. Highest-stakes call of my life ever
David Barnard:
I think the asymmetry of App Review is still lost on Apple. For indie developers our hopes and dreams (and sometimes our finances) hang in the balance, for the App Review team it’s just another app rejection among tens of thousands. I know they think they get it, they just don’t.
Dave Wood:
This is my biggest problem with Apple right now. Not the payment %. That Apple alone has the power to outright kill your business.
No company should be able to decide if another company (or their business plan) should exist. That’s a job for society & the governments we elect.
Jason Snell:
If developers don’t have to bet it all on an App Store acceptance, it also means that they might be more willing to build daring and interesting apps that currently are too risky. Sure, being on the App Store would remain the goal of most developers (it’s hard to imagine it wouldn’t remain the most important real estate on iOS), but many more things are possible if the all-or-nothing gamble is gone.
[…]
The App Review process has gotten a reputation as a capricious and draconian system, but Apple has probably approved many apps that reviewers aren’t thrilled about–either because they don’t want the trouble or because they’re concerned they’ll be limiting the utility of iOS itself if they don’t.
A no-longer-exclusive App Store might tighten its rules and become more opinionated. It might even be more willing to reject shady developers, blast scam apps, and decline certain types of apps altogether. Apple acts as if today’s App Store is just curating the platform, but it’s not–it’s judge, jury, and executioner. If you can fall back on telling developers to release their apps on their own, it’s easier to be a curator.
Perhaps, but there’s still the problem of the bad incentives that come from getting 30% of each scam sale.
Jeff Johnson:
Playstation and Xbox have around 2500 games each. They are truly curated.
App Store and Play Store have around 2-3 million apps each. They are not curated.
Apple would have to drop at least 99% of apps to make App Store “curated”. 20K titles is a reasonable number.
Michael Love:
This is an aspect of “consoles != phones” that Microsoft ought to push a lot more; if there were only 3000 iPhone apps and mine was one of them, I’d have no reason to complain about 30%.
(at the final PalmSource conference, they were working on a curated store charging 70%)
Francisco Tolmasky:
It’s really bizarre we cede major aspects of the
@AppStore’s narrative. As stated below, anyone who uses the store knows it isn’t curated at all, but we don’t push back on that. It’s like an energy CEO saying “but if we get rid of coal plants, the air will stop being so clean!”
Part of the problem is that it’s been repeatedly shown that people aren’t built to combat such bold lies, and at such high frequency. Just about every part of the @AppStore narrative from Apple is blatantly false. So you get decision paralysis as to which part to argue against.
Ross Boucher:
It really is bizarre. If third party stores could exist, someone would definitely have made an actually curated store by now.
Francisco Tolmasky:
I’d love an actually kid-focused
@AppStore, instead of an
@AppStore
that seems designed to get kids addicted to “games” that are thinly-veiled slot machines. But that would require losing 30% of the revenues from those games, which is the only true
@AppStore
guideline.
Previously:
Update (2022-03-09): tannedNerd:
I think the most frustrating part of app review is the inconsistency. Ive seen it happen while I worked at FANG level companies down to my own apps and doing contracting for startups. Each time you submit an update you are rolling the dice that a feature that was perfectly fine for every single app submission previously will be flagged for rule a violation.
A perfect example is one of the apps I do contract work for has a web view directory feature that doesn’t have any login pages on it directly, but after about 3-4 clicks you can get to one for the people who’s listings are on there. After 7 years of this app functioning exactly like this (and 1.5 years of sign in with apple existing) they decided it violated the app store rules because it didn’t feature sign in with apple... It took an app store appeal and almost 2 weeks of back and forth over the exact wording of the sign in with apple rules to get them to agree that the original reviewer had overstepped their bounds.
Although my absolute favorite rejection has been for putting a small apology to my users that I had quarantine due to a covid exposure and thats why the app update was delayed as I was unable to work and keep my family safe. It again took an appeal and 2 weeks for the apple to realize that my app hadn’t suddenly become a covid app, which should have been obviously from the first glance at the covid flagging.
Nick Heer:
So the iPhone’s App Store is not a carefully curated selection of only the best apps for the iPhone after all. It is a flea market with a few high-profile vendors. It is completely backwards. Great developers should be rewarded for building high quality apps. Instead, they are frightened every time they submit an update to the store while watching yet another crappy horoscope app with abusive in-app purchases creep up the charts.
Update (2022-04-11): Damien Petrilli:
It’s a forgotten point but this should be addressed by the upcoming anti monopoly laws.
Apple could prevent any competition by just “forgetting” to approve their accounts.
So far, the laws don’t seem to handle retaliation unless they forbid Apple app signing entirely.
Ben Sandofsky:
Our bug fix update has been rejected because of our app preview. It was added 18 months ago with zero complaints from App Review. I am getting extremely tired of this theater.
App Review App Store App Store Scams Business Halide iOS iOS 15 Sideloading Sign In with Apple
Sarah Perez:
The judge has ruled that at least half the claims can proceed and is giving Eleftheriou the opportunity to amend the remaining items that were dismissed.
[…]
In his own lawsuit against Apple, Eleftheriou aims to document what he alleges were an unfair series of rejections for his Apple Watch keyboard app, FlickType, from the App Store. At the time, Apple told Eleftheriou his app offered a “poor user experience” and noted full keyboard apps were not allowed for Apple Watch. But, he says, it then allowed competitor keyboard apps as well as third-party apps (like Nano for Reddit, Chirp for Twitter, WatchChat for WhatsApp and Lens for Instagram) to launch on the App Store — the latter using an integratable version of the FlickType keyboard, in seeming contradiction to Apple’s earlier claims over FlickType’s poor usability.
When Apple chose to approve FlickType in January 2020, the keyboard app reached the App Store’s top 10 paid app list and generated $130,000 in revenue during its first month, Eleftheriou said. But this soon made it a target for scammers who launched barely usable competitors boosted by fake ratings and reviews, he claims.
Via Kosta Eleftheriou:
In court, Apple didn’t address each cause of action individually, but instead made “a series of broad arguments” claiming that even if this is all true, it shouldn’t matter because they’re not breaking any laws.
[…]
While they advertise the App Store as a “safe and trusted” marketplace and “a great opportunity for all developers to be successful”, Apple also told the court that I couldn’t “reasonably and justifiably” rely on such “general statements.”
[…]
Apple has blocked entire categories of apps from ever seeing the light of day, for self-serving reasons.
A wave of lost innovation is just waiting to happen, and we shouldn’t have to wait for Apple to approve it.
Previously:
Antitrust App Store App Store Scams Apple FlickType iOS iOS 14 iOS App Lawsuit Legal watchOS
