This is causing a lot of ... manual effort for our accounting teams. Ideally the accountants should use only the Financial Reports, which are definitive (in some sense). Is there some reason why your accounts - rather than your "sales tracking", or whatever you want to call it - need the extra detail of the other reports?

In iOS 1.72 and newer, check transaction.offer.paymentMode == freeTrial, and then status.renewalInfo.willAutoRenew, then status.renewalInfo.renewalDate. For a while I was confused because I thought the free trial was part of the first subscription period and the renewal date would be after e.g. 1 year. But no, the free trial its its own subscription period of e.g. 3 days. I would not try to calculate how many days are remaining; just show the renewalDate. (Because: https://xkcd.com/2867/ )

C++ doesn’t have any sort of package manager It has vcpkg, but that's not an Apple product so it doesn't exist apparently. You might be able to just vcpkg install libjxl --triplet=arm64-ios, or something. Not that I use it. The stack of package manager (vcpkg) --> build system (cmake) --> low-level build system (make) --> compiler (clang) tries to make things easier for you by hiding the details of the lower levels behind easier-to-use higher levels. But in my experience, they rarely succeed at that; you inevitably get an error from a lower level that is impossible to relate to the higher-level command that you actually ran. Learning vcpkg doesn't remove the need to understand, and be able to debug, cmake, make and the compiler. The same is true of autotools and to some extent xcode. Package managers, IMO, work well for binaries i.e. homebrew or dpkg, and maybe for interpretted languages, e.g. npm, but not really for compiled languages.

% cd /usr/local/src/ % git clone https://github.com/leetal/ios-cmake.git % cd /usr/local/src/ % git clone https://github.com/libjxl/libjxl.git --recursive --shallow-submodules % cd libjxl At this point I hacked third_party/brotli/CMakeLists.txt to disable three lines around line 214: # install( # TARGETS brotli # RUNTIME DESTINATION "${CMAKE_INSTALL_BINDIR}" # ) Without this, I was getting this error: CMake Error at third_party/brotli/CMakeLists.txt:214 (install): install TARGETS given no BUNDLE DESTINATION for MACOSX_BUNDLE executable target "brotli". The clue is the word "executable" in the message; we don't want it to try to build any executables, but it seemed to be trying to build a brotli executable. My change is a hack. Anyway: % mkdir build.ios % cd build.ios % cmake .. \ -DCMAKE_TOOLCHAIN_FILE=../../ios-cmake/ios.toolchain.cmake \ -DPLATFORM=OS64 \ -DENABLE_BITCODE=false \ -DENABLE_VISIBILITY=true \ -DCMAKE_INSTALL_PREFIX=/some/path/ \ -DBUILD_SHARED_LIBS=false \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_TESTING=OFF \ -DJPEGXL_ENABLE_TOOLS=false \ -DJPEGXL_ENABLE_MANPAGES=false \ -DJPEGXL_ENABLE_BENCHMARK=false \ -DJPEGXL_ENABLE_EXAMPLES=false \ -DJPEGXL_ENABLE_JNI=false \ -DJPEGXL_ENABLE_FUZZERS=false % make % make install You should now have .a static libraries in /some/path/lib Let me know if that works for you.

I have a vague recollection... I've found the code in question, where I have this comment: // The glibc docs used to say: // In the GNU library, the functions [cfsetispeed, cfsetospeed, etc] accept // speeds measured in bits per second as input, and return speed values // measured in bits per second. Other libraries require speeds to be indicated // by special codes. // At some point, however, this note has been removed and currently the // Bnnnn definitions are not the same as the numeric values; attempting to // use a numeric baud rate will result in an error. So Bnnnn symbols for // baud rates must be used. I added that in 2017.

I have a vague recollection that expecting the Bnnnn baud rate constants to equal nnnnn can fail on other platforms too, maybe old linux versions or unusual architectures or old glibc versions or linux running a libc that isn’t glibc or something. Use the ioctl - that’s what it’s for.

We want to try to find a more specific cause of the error. That’s probably not a productive use of your time. Instead, spend the time learning how to use Address Sanitizer, and see if it can find any other similar bugs in your app.

We need to know whether iOS18 has made any improvements to the API for operating memory such as memset. No. Is memory management more stringent? No. Why do versions below iOS18 not cause problems? You were lucky. The important question is: why did you not get a compiler error, or at least a warning, about this? Were you ignoring warnings?

Here's what I used for that app, which was approved: When you tap the app's Location button, a marker will be displayed on the map at your current location. For example, if you're standing on the summit of Denali and you tap the Location button, the app will show a marker on the map at the summit of Denali (subject to the accuracy of the data received from the device). The app will continue to receive location updates from the device and move the marker until you turn off the Location button. When you tap the app's Record button, the app will display a line on the map indicating where you have been, and will store this data in a file. None of this data leaves the app, unless you choose to export the file containing the recording.

I kind of thought there’d be at least a reply from an Apple Engineer to each post? Funniest post of the year!

I normally tell cmake to build Makefiles (which is possibly the default?), rather than using -G Xcode. Is that error telling you that it is trying to build a dynamic library? For iOS builds, you probably want to tell it to build only a static library, and not to build executables i.e. the cjxl / djxl utilities. Something like -DBUILD_SHARED_LIBS=false ? If you're lucky, there will be a cmake invocation that will list all the available flags. You're already turning off testing, see what else there is.

If something builds for arm64 macOS, shouldn't it work with iOS/iPadOS, which is also arm64? No, unfortunately not. I thought you included it and that making libjxl work on iOS is an easy/supported process. I do include it in my iOS app at runtime. Doing so was not a particularly easy process. I used something from github called "ios-cmake", which is a pile of scripts and/or cmake configuration fragments.

That cmake invocation will build macOS libraries I think. I'm not a cmake expert. Search github for "ios-cmake".

https://www.apple.com/uk/newsroom/2024/05/app-store-stopped-over-7-billion-usd-in-potentially-fraudulent-transactions/ Apple terminated 118,000 developer accounts in 2023, down from 428,000 in 2022. That's one every 5 minutes. There are lots of posts like yours on this forum. I don't recall anyone ever replying to say that their account was re-instated. The moral is, don't be a full-time Apple developer; make sure you have another job that pays enough to pay your mortgage and the bills. Just treat your income from Apple as a nice bonus that could go away at any moment.

This is not a general problem; I've found reviews to be fast recently. (Only 20 minutes in one case!) I guess either you have hit some sort of "special review", or something has got stuck. Sorry, I don't know what you can do about it.