Switches vs Remotes
A switch is completely different from a remote because the switch has “state.” That is, a switch by itself can be either “on” or “off.” So if you press a switch, it turns on, and it tells the hub that it turned on. Or, the hub can just send a message to the switch to turn on.
A remote, which SmartThings Will usually call a “button controller,” has no state of its own. It’s neither on nor off. When you press a button, nothing happens on the remote itself – – it just sends out a message to another device that its button was pressed. Ideally, we want the hub to receive that message. If the hub can receive a message from the remote, and the message is specific to which button was pressed, then we have a device that can integrate fully with SmartThings. 
What will happen is that there will be an automation/smart app set up so that when the hub receives the button press notification, The automation can treat that as a trigger and have something else happen.
Remotes that don’t notify the hub of a button press
Some remotes, however, never send a notification to the hub when the button is pressed. They just think they are supposed to talk to some other device directly.
Some people still use these as a parallel means of control. You press a button, and a lamp comes on, and eventually SmartThings knows that the lamp came on. But SmartThings never knows the button was pressed.
As long as the remote doesn’t steal the lamp away from SmartThings, so the Lamp ( not the remote, just the lamp itself) can still be controlled by either the remote or the hub, the remote can still be useful. It’s just not as useful as a full “button controller” that sends notification of button presses to the hub.
The worst case
The worst case is if the remote only works with the lamp by stealing the lamp away from SmartThings so that the hub can no longer send commands to the lamp directly. So we hope that won’t happen.
An example of a remote that can be used as either a button controller or a parallel means of control – – you decide
The Osram/Sylvania Lightify Smart Dimmer is an interesting example, because it is a zigbee device that can be used as either a button controller (sending a notification of each button press to the hub) or as a parallel means of control (sending instructions directly to some specific bulbs, but not stealing those bulbs from the hub). It just depends on which device type handler you use.
Many people like it as a button controller, because then they can have it trigger anything that SmartThings controls, including Z wave devices, because the dimmer sends the button press notification to the hub, and then the hub sends the commands to the other devices.
But some people set it up as a parallel means of control because then it is very very fast. But it will only be able to control a few nearby Zigbee bulbs.
Here for reference are the two alternative device type handler’s for the Lightify device. You have to use one or the other, and they work very differently.
As a button controller ( notifies the hub of each button press)
As A parallel means of control (does not notify the hub of the button presses, but instead speaks to the bulbs directly)
But again, this particular lightify dimmer is unusual in that it is up to the user which DTH to use and how to set it up to communicate with a Bulb – – either through the hub or directly.
Most remotes will need to be set up as one or the other, because they just won’t work in both ways. But I wanted to put both DTH links here since first of all, we don’t really yet know which of the two ways the IKEA remote would be able to use. (Or of course if it’s going to end up being one of the worst case devices, meaning it can be paired to SmartThings but it can’t be used because it always steals the lamps away from the hub. 
). And it’s important to understand the differences when you get ready to start writing a device type handler.
Writing the DTH
The following thread is my favorite example for how someone who had never done much coding set out to write a DTH for a new zigbee remote, in that case A three button Key fob. It was a device that was eventually able to be set up as a full button controller, sending a notification of each button to the SmartThings hub. In the thread, you can see exactly the steps the person went through to get the information needed to write the DTH.
Because the IKEA Remote is intended to control zigbee lights, I think you may be able, as has already been suggested in this thread, to start with the appropriate lightify DTH and then modify that. Who knows, the IKEA remotely may even end up being able to use either control method, like the lightify, and you will end up with two different DTH is that users can choose between. But regardless, you need to get some information from the IKEA device itself, and the thread I just posted will show you how that process works.
Good luck!
how to organize the code discussions
I suggest that, just as was done with the lightify device, you start a new topic for each DTH project under, well, “projects.” In that thread you can discuss what you’re trying to do, get help from other people, brainstorm any problem if you run into. This will be your development thread.
https://community.smartthings.com/c/projects-stories
Then when you have a completed DTH ready for beta testing, start a brand-new thread under community – created device types and put the link to the github where the code is in the very first post of that thread. But wait to post in this section until you have a working device type handler at least ready for beta testing.
That way in the future when people are just looking for the DTH, they will be to find it quickly. But during the development process you will be able to get help and feedback from other community members in the development thread. And you will keep this thread, which really should be for discussion of the devices themselves, from getting flooded with code discussions. 