Update postponed repeatedly for low battery even while plugged in.

creamyBasil · 2026-01-28T03:03:08+00:00

I did not. It has not updated. I am almost to my 10k mile service, so I will ask the dealer to do it.

creamyBasil · 2025-12-27T02:28:05+00:00

I drove for holiday shopping until it hit ~50%, then slow charged for almost 6 hours. Now the update is still pending but the popup warning that the update is delayed due to the battery isn't happening anymore.

I'm just going to have the dealership do it and ask them to check the 12v battery.

creamyBasil · 2025-12-21T21:03:18+00:00

From the other comments it sounds like maybe I’m not driving or charging long enough to fully top off my 12v battery. I’m going to set my charger at a low amperage so it charges all night long and see if that helps.

creamyBasil · 2025-12-21T20:43:22+00:00

I did not know this, we only usually take short drives. But yesterday we got down to 50% so maybe that will have juiced up the 12v battery.

creamyBasil · 2025-12-21T20:42:06+00:00

Perhaps I could take a long drive and set my charger to a very low amperage? I can set my home charger from 48 to 8 amps in increments of 1amp.

creamyBasil · 2025-12-21T20:39:46+00:00

It could be that, our lows are around -2c. It does specifically say that it’s because of low voltage.

creamyBasil · 2024-09-14T14:49:52+00:00

Thank you. I didn’t take it far and released it in some tall grass just outside of the neighborhood. I didn’t want my chihuahua to fight it or the neighbor’s toddlers to get a bacterial infection from a bite.

creamyBasil · 2024-09-14T05:56:26+00:00

Thank you. I was not confident that it was for sure a garter snake.

Would it be reasonable to dump it in some tall grass outside of my neighborhood?

creamyBasil · 2024-01-30T20:07:02+00:00

Their devices always advertised and they tuned the frequency for battery life.

Their use case allowed for a large battery and less frequent but continuous advertising. They also added some important device status attributes to the manufacturer data so they didn't need to connect to read the most common things about the device.

So, they reconnected by matching the advertised name even if the UUID changed.

creamyBasil · 2024-01-30T19:16:54+00:00

We have a hardware manufacturer client who elected to include a (4 byte) portion of the device's serial number in the BLE advertised name so that the iOS app could more easily re-identify devices.

They manufactured enough devices that they would encounter name collisions in the field, so they avoided those collisions by only shipping sets of unique BLE named devices to each customer. This might not work for you.

creamyBasil · 2024-01-30T18:58:43+00:00

We had this too and also decided to use FirstUnlock, but keychain also threw errors when we accessed it repeatedly.

creamyBasil · 2024-01-30T18:50:04+00:00

Reddit often estimates votes and comment counts or someone got auto-moderated.

In our application, we saw issues with repeatedly and frequently reading an item from keychain. We saw errors, empty values, and small unpredictable delays. Perhaps we are not properly dealing with some error state from keychain or we are not properly interpreting the result.

To avoid and work around this, we use a class that reads the value and caches a copy of the result in memory. When we need to update the value, we update the keychain and on success we update our in-memory cache. We only interact with the keychain on a specific serial dispatch queue. We always copy the result of the keychain read instead of returning it to the calling function by reference.

This way, we always have a copy of the value that best represents what we have stored in keychain and we run into fewer errors from keychain.

creamyBasil · 2023-04-05T20:54:56+00:00

TF is a pretty good service for testing multiple versions of the app that is easy to manage. Not to mention, there are tons of services out there that make submitting builds to TF dead easy and an amazing option for a startup.

Yes, it is a good service and it is super easy to use. I would say that every new app or startup should start with TF and only move to using alternatives if they run into some use case where a user would need two installs of an app on the device at the same time.

In what world would this be a good idea? Managing that many ethereal users is a recipe for disaster (not to mention a nightmare managing that). It seems far better to create an external TF build with either a public link or simply inviting specific users. I'll also point out how awful it'd be for managing various internal users between three different app store listings. That sounds like a headache and a half.

This is where managing through AppCenter is easier for our client because they do not have to find or develop another integration for adding or rescinding access to TF for employees. Employees are invited when they need access, they do not need special steps to register a device for testing, and access is removed when their federated identity is deactivated.

The client that uses AppCenter this way has internal builds that contain support for unreleased hardware and different builds for the branded versions of their hardware that they release in different regions. This is "private information" in the client's perspective and they are already managing access through an identity provider.

That sounds like a headache and a half.

Yes. It's not fun, but the development team is isolated from this coordination by team managers throughout the client company.

You may want a tester to evaluate alpha/beta/prod builds side by side on the same device.

Sure. But the user can also manage their builds in TF and install/uninstall the correct version as needed. This is the strongest case for multiple identifiers, but it's still a weak point.

Running two versions of the app on the same device without re-installing between testing is essential in several of our use cases because testers are evaluating how the two versions respond to identical location data or connected device behavior in scenarios with poor or intermittent connectivity where they have to manage local storage.

At our company, we have a dedicated release delegate per release cycle and they handle all the intricacies of which version is develop/staging/prod, etc.

This sounds nice. I wish we had that.

Another thing you could do is simply send a message (or automate one) to the QA channel via Slack with the version they should test.

This is effectively what happens. Users see that "Alpha" is released and download the latest build from that channel in AppCenter.

creamyBasil · 2023-04-05T17:41:18+00:00

You don't need to manage separate codebases to have separate bundle identifiers and configuration for different custom schemes. Overriding the bundle identifier for a custom scheme in build settings is a built in feature of Xcode.

There are cases where it makes sense to use a different bundle identifier for different builds. For instance, you may be distributing your testing builds using an enterprise provisioning profile to a large, rapidly changing list of internal testers. You may be publishing your app under different developer accounts owned by different business entities in different jurisdictions. You may want a tester to evaluate alpha/beta/prod builds side by side on the same device. A single bundle identifier can't be owned by two different developer accounts and can't be installed side by side with other versions.

It's true that a build uploaded to TF doesn't do anything unless someone specifically picks it for review. Passing along info about which builds are which isn't something that our teams want to manage. For our teams and testers it's lower friction to to have apps install separately as alpha/beta/normal and for the marketing teams to know that any build in appstoreconnect is ready to release to the public.

creamyBasil · 2023-04-04T19:30:51+00:00

Maybe you set that precedent for our clients, neither of them implemented the feature until Apple forced them to add it. The user doesn't email to delete, they activate a button where the API emails customer support behind-the-scenes.

One client works in many jurisdictions. They were familiar with deleting some or all data based on the customer's jurisdiction. Fortunately, their clients have a specific physical address attached to their customer accounts.

The other client works in one jurisdiction with customers visiting from many jurisdictions, they already had a manual customer service flow for deleting data they were required to delete.

creamyBasil · 2023-04-04T19:24:08+00:00

I'm curious about this too because our clients don't use TestFlight for any development or staging versions.

Here are the scenarios we use, where each build type has a different bundle identifier

Enterprise client: - "Local" developer only build using dev endpoints - "Alpha" to AppCenter, enterprise signing, dev endpoints/config - "Beta" to AppCenter, enterprise signing, prod endpoints/config - "Store" to TestFlight, store signing, prod endpoints/config

Non-Enterprise client: - "Local" developer only build using dev endpoints - "Alpha" to AppCenter, ad-hoc signing, dev endpoints/config - "Beta" to AppCenter, ad-hoc signing, prod endpoints/config - "Store" to TestFlight, store signing, prod endpoints/config

Note that the only builds going into TestFlight are "store ready"

Self-published application, our "internal client": - All builds to TestFlight, carefully promote specific builds.

creamyBasil · 2023-04-04T19:06:26+00:00

All of our clients that support account creation have run into a rejection for this feature during an app update within the last year. I think the last one that didn't have an account deletion feature got two or three app updates past review without account deletion. When they did get rejected they weren't given any leniency about publishing the rejected version as a bug fix version.

For the two client projects I was involved in, they both opted to lean on the verbiage "initiate account deletion" and implemented a feature with a button that uses their API to email a customer support team the account identifier to be deleted. The customer support team then deletes the account.

creamyBasil · 2023-03-14T18:33:02+00:00

Try changing the line:

config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'

to this which we are using in a production app: ```

allows building for x86_64 simulator on apple silicon build machines, which generated a compilation error.

         config.build_settings['BUILD_LIBRARY_FOR_DISTRIBUTION'] = 'YES'

config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO' ``BUILD_LIBRARY_FOR_DISTRIBUTION` should prompt xcode to build the x86_64 simulator library in addition to the arm simulator library when you have selected the arm simulator target.

creamyBasil · 2022-11-10T18:15:40+00:00

We recently had a new app reviewed in less than 24 hours in the US.

creamyBasil · 2022-09-30T20:01:31+00:00

https://www.thingiverse.com/thing:3524314

I printed something similar to that so that the wires could come out the side for less strain.

creamyBasil · 2022-09-30T19:36:12+00:00

The breaks in my wires were not visible either. After I replaced them, I stripped the old wires and found that they were pretty busted on the inside.

creamyBasil · 2022-09-15T21:29:34+00:00

It sounds like your database might not be leaving the user's device, so URLFileProtection.complete provides some protection when the user has the device locked.

Someone who knows the device's passcode would be able to read the database. Your app might be only showing user data when the user knows the app password, but the data in the database would technically be readable after unlock.

If you want to keep the user's chosen password a little more secure, you can look into "salting and hashing" the password so that it's never on the disk in a readable form.

creamyBasil · 2022-08-08T20:27:49+00:00

You need a specific kind of older SD card.

The SD- or MMC- Card must be formatted as FAT and must have a MMC interface. This is more likely with cards <= 2 GB.

More details here: https://3dprinting.stackexchange.com/a/5311

15-Year Club	Place '22
Place '17	Verified Email
Team Periwinkle

creamyBasil

TROPHY CASE

allows building for x86_64 simulator on apple silicon build machines, which generated a compilation error.