A map editor is really a good way to go. It depends on how your world works though and what you want. Normally in game programming the saying is to not hard code any data... and it's all data, lol. Really though it's good advice to keep your data out of code.
With a map editor you can visually see where things are instead of guessing with code, compiling, running... repeating many times. If a full map editor is overkill for what you're doing though you can take short cuts. For example for one of our games we have about 25 scenes. Our artist is drawing the maps by hand, then I go through and pick out the collision points which I store in a plist. The plist is then loaded at run time along with the current scene. Having a map editor though would allow the artist to define the points (or make it a little easier for me). But having this in a data file allows me to only write one class just to load a map and makes the code a lot easier.
EDIT:
Oh and a map editor essentially just creates a file for you to load at runtime. So in your files (binary are usually best for speed), you just put what a level may hold. Simplified example:
file
-solids (Array)
--item1 (Dictionary)
---x - 10
---y - 10
---width -32
---height - 10
--item2 (Dictionary)
---x - 50
---y - 0
---width - 8
---height - 8
-entities (Array)
--item1 (Dictionary)
---type - blue steel sword
---x - 120
---y - 82
...
With a file like that I can have a class with storage types such as Dictionaries, Arrays, Lists... and my one class responsible for loading the level just loads that data, creating cocos nodes, collision objects, etc depending on the type of item in the level.
