the chip we’re planning to use will have around 340k with some used by the OS and rom mask, some by our vivokey applets, and the rest free for user applet loading via fidesmo… so i would guess around 250k-300k or so. however, this storage space is for applets only, so if you want to store anything, you would need to write an applet that provisions some amount of user data space and shuttles the data for you. this is nothing like even the desfire chips… this is a secure computing environment that runs software (applets).
when most people ask about “space” they are talking about user memory that can read from and write to with standard NFC commands… i.e. NDEF data… your phone will want to send ISO14443A style APDU commands to the chip to read memory blocks and write to memory blocks, but the smartcard chip does not understand those commands… it is operating as an ISO7816 smart card, and that command set has no provisions for memory read/write. What it does have is a set of commands for deploying, selecting, communicating with, and removing smart card applets.
put this together and basically what you’ve got is the need for our NDEF applet (vivokey.com/ndef)… in short, with the applet installed, your phone will talk to the chip, start doing some poking around, realize it’s not dealing with an NFC Type 2 chip, then switch up to NFC Type 4 and look for a very specific AID (applet identifier). The AID for NFC Type 4 NDEF data storage is D2760000850100 which is the same AID that is formatted for use in a DESFire chip (xDF2, flexDF, etc.) for use with NDEF data. at this point, the NDEF applet is “selected” meaning the phone can now talk to application D2760000850100 on the chip, which supports memory read/write commands.
the size of the NDEF container is what matters… so on the DESFire EV2 chip, which has 8k, you can define an NDEF container that is 1k, 2k, 3.878317k, 5.89k or all 8k… if you do that, then you can write up to 8k of NDEF data into the container that is formatted into one or more NDEF messages, each of which can have one or more NDEF records. Typically there is only ever one NDEF message, and inside that there are one or more records… so in NFC Tools when you want to write multiple things to your tag, you are creating multiple records within the single NDEF message on the chip… it just happens that on the DESFire that NDEF data is stored inside of an application ID that is defined as a generic binary data storage “file” (applications are called files on DESFire chips) with a specific AID of D2760000850100… on the Apex, the AID D2760000850100 will be a special javacard applet that also supports generic memory read/write commands for storing NDEF formatted data… and the size of that container on the Apex can, in theory, be up to 300k or more… but because of the limitations of data storage and throughput practicalities, we have limited the maximum size of the NDEF container to 16k for the NDEF applet on Apex. We did have a 32k size at one time, but it caused actual problems because it took so very long to provision NDEF data storage within the applet that phones and readers were basically timing out the NFC command and giving up.