Resolution changed to Open. Sad. It was "will fix in future release" before.

Agreed, still there 2 years after.

Fixed in iOS 18.4 beta

Duped as FB16544363

Thanks for posting this workaround. In my case, I was constraining a hosting controller relative to the keyboard layout guide, so I suppose the safe area insets changing caused tiny changes in the intrinsicContentSize calculation within UIHostingView.

As of iOS 16.4, you can set hostingController.safeAreaRegions = [] to work around this bug using public API.

Is working on xCode Version 16.1 (16B40) with iOS Simulator 18.1

I use the iOS 18 Simulator and I can't manage to log in to my app with Face ID. It is crashing all the time.

See:

• Linux has more than 10x better performance -- M2 Pro vs that same M2 Pro Running an Ubuntu VM: https://x.com/nullvoxpopuli/status/1843656141638664607
• Linux has more than 10x better performance -- M3 Pro vs AMD 6440U w/ Ubuntu: https://x.com/nullvoxpopuli/status/1843399757978382367

My disk test:

• have pnpm installed
• git clone git@github.com:NullVoxPopuli/ember-performance.git
• cd ember-performance
• pnpm install
• time ( git clean -Xfd && git clean -fd )

Are you still experiencing the same issue? Did you find any solution?

Several months after filing this bug, we opened a DTS TSI in the hopes of gettting movement from Apple toward an OS release fix (due to numerous user complaints), which was immediately refunded back to us by Apple with the following note:

" There is no workaround DTS can provide for Feedback ID FB13619556 and it's still under investigation. Please continue to track the problem via the bug report. "

We've since abandoned any further work on MailKit extensions due to the lack of functionality it provides and the multitude of unfixed bugs still present in Mail & MailKit over 2 years after its initial release.

I am facing this issue on MacOS Sequoia version 15.1.1. It disconnects after exactly 24min. Is there any solution to this issue? It's a profile installed VPN and I have the mobileconfig file for it.

The complete view code to reproduce the problem is simple this:

var body: some View {
	Group {
		if displayAsTable {
			Table(of: Item.self) {
				TableColumn("Date") { item in
					Text(item.timestamp!, formatter: itemFormatter)
				}
			} rows: {
				ForEach(items) { item in
					TableRow(item)
				}
			}
			
		} else {
			List {
				ForEach(items) { item in
					Text(item.timestamp!, formatter: itemFormatter)
				}
			}
		}
	}
	.onChange(of: orderAscending) {
		items.nsSortDescriptors = [NSSortDescriptor(keyPath: \Item.timestamp, ascending: orderAscending)]
	}
	.toolbar {
		ToolbarItem(placement: .navigation) {
			Picker("Display", selection: $displayAsTable) {
				Text("Table").tag(true)
				Text("List").tag(false)
			}
		}
		ToolbarItem {
			Button(action: addManyItems) {
				Text("Add 10000 Items")
			}
			
		}
		ToolbarItem {
			Picker("Order", selection: $orderAscending) {
				Text("Ascending").tag(true)
				Text("Descending").tag(false)
			}
		}
	}
}

Given we now have onChange(initial:) this is now how I would like to change the predicate:

struct RemindersList: View {

    let todoList: TodoList

    @Query private var reminders: [Reminder]

    var body: some View {
        List(reminders) {
            ...
        }
        .onChange(of: todoList, initial: true) {
            let todoListID = todoList.persistentModelID
    
            let predicate = #Predicate<Reminder> { reminder in
                reminder.todoList?.persistentModelID == todoListID
            }
            _ reminders.predicate = predicate
        }
    }
}

The following workaround isn't pretty, but it works:

[pa addPointer:nil];  
[pa compact];

I'm guessing NSPointerArray may be implemented such that if no add/insert/replace has occurred that sets a value to nil, it assumes that no pointer in the array could be nil and it can skip compaction. This may have been correct behaviour prior to ARC weak pointers, but it's no longer the case today.

I've noticed that happen on Xcode16, while I'm running on Xcode15 it works fine

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sysexits.h>
#include <time.h>

// We will write a file with two chunks above:
// * 13.6 GB of 'x' chars at the beginning of the file.
// * 200 bytes of 'x' at 395 GB mark.
//
// We expect the file size to be 395 GB, but the bytes between 13.6 GB and 395 GB
// should be a hole and not take up blocks on disk. We expect disk usage of at most 20 G.
//
// In reality on most macOS (Sonoma 14.5, Sonoma 14.7.1) we see the disk usage exploding to 395 GB.
// The write(200 bytes) invocation gets stuck in the kernel for 30s generating the zero bytes (can't even kill -9).
//
// Note that if we ftruncate the file to the desired size ahead of time, the issue doesn't arise.

struct
{
    off_t offset;
    off_t length;
} chunks[] = {
    {0, 14617935872},    // 13.6g
    {424128040960, 200}, // 395g
};

off_t desired_size = 424128041160;           // 395g
off_t max_expected_disk_usage = 21474836480; // 20g (not expecting hole to exactly line up)

int write_xs(int fd, off_t length);

int main(int argc, char **argv)
{
    if (argc < 2)
    {
        printf("usage: explode <filename>");
        return EX_USAGE;
    }

    int out_fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC, 0644);
    if (out_fd < 0)
    {
        perror("open");
        return EX_IOERR;
    }

    // If the file is truncated ahead of time, the bug is not triggered.
    // if (ftruncate(out_fd, desired_size) < 0)
    // {
    //     perror("ftruncate");
    //     return EX_IOERR;
    // }

    size_t nchunks = sizeof(chunks) / sizeof(chunks[0]);
    for (size_t i = 0; i < nchunks; i++)
    {
        printf("chunk %ld: offset=%lld length=%lld\n", i, chunks[i].offset, chunks[i].length);

        clock_t seek_start = clock();
        if (lseek(out_fd, chunks[i].offset, SEEK_SET) < 0)
        {
            perror("lseek");
            return EX_IOERR;
        }
        clock_t seek_end = clock();

        clock_t write_start = clock();
        if (write_xs(out_fd, chunks[i].length) < 0)
        {
            perror("write");
            return EX_IOERR;
        }
        clock_t write_end = clock();

        printf("chunk %ld: seek time %.0f ms, write time %.0f ms\n", i,
               (double)(seek_end - seek_start) / CLOCKS_PER_SEC * 1000,
               (double)(write_end - write_start) / CLOCKS_PER_SEC * 1000);
    }

    struct stat out_stat;
    if (fstat(out_fd, &out_stat) < 0)
    {
        perror("fstat");
        return EX_IOERR;
    }

    if (out_stat.st_size != desired_size)
    {
        printf("resulting file size doesn't match (got=%lld, want=%lld)", out_stat.st_size, desired_size);
        return EX_SOFTWARE;
    }

    off_t disk_usage = out_stat.st_blocks * 512;
    if (disk_usage > max_expected_disk_usage)
    {
        printf("resulting disk usage is higher than expected (got=%lld, want=<%lld)", disk_usage, max_expected_disk_usage);
        return EX_OSERR;
    }

    if (close(out_fd) < 0)
    {
        perror("close");
        return EX_IOERR;
    }

    return EX_OK;
}

// writes `length` 'x' chars to fd.
int write_xs(int fd, off_t length)
{
    int blocksize = 65536;
    char *buf = malloc(blocksize);
    memset(buf, 'x', blocksize);

    while (length > 0)
    {
        int n = length > blocksize ? blocksize : length;

        ssize_t w = write(fd, buf, n);
        if (w < 0)
            return -1;

        length -= w;
    }

    return 0;
}

As shown in the updated sample https://github.com/AndyDentFree/swiftgooey/blob/main/CrashVanash/ the fix is to add animation of the button being hidden.

This appears to add enough delays into the process that the race condition doesn't occur - the button is automatically disabled before it is hidden, so the auto-repeat stops.

Still not fixed on iOS 18.x

Works in Xcode 16.1 (beta) with iOS 18.1