DS flash cart internals are not my forte but it runs as follows
The way DS binaries run has been covered already- things are catapulted into the memory when the game is launched and the code runs from there. The actual DS cart with the level data, sounds and whatever else is not visible directly in memory but it can be accessed via a relatively complex (compared to all that came before it anyway) system. qaz00 already linked up a nice explanation at
http://nocash.emubase.de/gbatek.htm#dscartridgesencryptionfirmware and
http://files.darkfader.net/ds/files/cartridge.txt takes care of most of the rest.
The flash cart has three jobs
1) Sit on the DS pins and convert normal DS calls into something it can read from a memory card and feed it back quickly enough to be useful on to the DS. Later on fake this functionality in a more in depth manner (originally they did it all but that is not the way the DS works and so Nintendo made this "deficiency" an anti piracy method- see "below 8000h").
2) Sit on the DS pins and convert normal DS calls concerning save data into something it can make sense of. Unlike just about every other DS game pokemon stuck something extra here (a selector switch leading to a IR port or the normal save stuff- hence the normal save dumping tools doing nothing here). Various methods were employed to sort this out by different flash cart teams.
3) Where conversion fails or it is otherwise beneficial then apply patches, be they automated or designed by the flash cart menu developer, to the binary at runtime. This could be anti piracy, cheats, soft reset and other bonus functionality like savestates, text readers and cheat searching tools.
Flash cart developers took 3) several steps further and made a menu that loaded as the initial game, then redid the game loading procedure with a ROM the user selected (and any additional patches).
To accomplish all this the flash cart developers used many things. Pretty much all DS flash carts use complex programmable chips of either the FPGA or CPLD class of devices. By the way you will have to learn how to program these devices and though they are very nice to their friends (being programmable they can be taught to whatever you like rather than go to the expense of building something or hoping someone else built a chip that does what you need- I am sure you can see why this is invaluable to those wishing to be an electrical engineer*) they are noted for being somewhat picky as to what they call friend.
*you will likely also benefit from some fairly high end electrical engineering skills here and in the project at large.
Your hypothetical device would then do most of that but pass over any requests for the game that did not need to be modified to the original cart and pass things back (rather than just doing the far simpler method of handling the SD card like a normal flash cart), also the same for the IR side of things and probably any saves. This is a fine method if you are trying to develop an initial hack (see the passme and how it worked) or otherwise can not be bothered to spend the time developing a full hack for whatever reason (hack that works one in 20 but with stuff you have there to hack any fool that can operate the copy and paste commands and read a 200 word guide can do is quite a leap). Given all that in the case of the DS is long long in the past it is a lot of pointless work for no gain, not even a nebulous legal one.
That said there is no "homebrew" DS flash card (and I do not believe the R4 makers kit that was being sold on various Chinese underground markets ever leaked), between the woodRPG source, things like
http://www.natrium42.com/projects/serial.php and a lot of reading you might be able to get something done though.
On xcode- I am not sure C++ is a suitable language for much of this (you are probably better off with C, especially if you are developing electronics) and xcode is fine I guess but it is not a magical thing and a simple text editor (or more likely one that is slightly more geared for programming- aside from messing around developing for idevices I have no special need to play there so I am not sure what goes on apple stuff) will serve most of your purposes. Similarly if you find yourself programming for nice FPGA/CPLD devices beyond xcode being a glorified text editor at its heart it would probably actually be more difficult to code for your new chips (I doubt the dev tools of your would be chip and xcode speak to each other that well).
Once again though I say give up and get a flash cart: they can do what you need quite happily and ignoring what follows in the next sentence it requires a lot of effort, some fairly rare skills and most likely a considerable expense (if you are having to scrape to find a hard drive then far more than that). If all you want is a pokewalker I still say use cheats instead (question- would you ever shake it to fake the pedometer, if so we have cheats for a reason and if not you lie) but you could probably rip the IR guts out of a copy of the game (or replicate them- they are not that complex from what I have seen) and solder it in; this is where I was heading with the cart selector idea but it is probably dismissed for power reasons if not the possibility of flash carts themselves using the save pins as a comms channel (I do not think this was the case but it is an appealing idea that will have to be investigated further).